

Git vs. Mercurial: Please Relax - Anon84
http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/

======
ajross
I loved this article. That being said:

 _This brings us to another of git’s faults: its documentation is terrible.
Man pages are no longer a sufficient replacement for a good, well-updated wiki
or reference work;_

Huh? This is the kind of thing that IT pedants say when they don't have any
better arguments. There's absolutely nothing wrong with a good man page (or,
to be sure, any documentation format at all). /usr/bin/man, in 2008, is still
my first choice for looking up the interface to system calls, C APIs and
command line utilities like git.

Now, could some of git's man pages use some work? Sure. But make that the
criticism. Smacking about the format is just dumb.

~~~
jrsims
...What if there was a wiki that people could use to participate in the
documentation, and then that documentation would become the man page with the
next release? Everyone wins?

I like and use both man pages and wikis, but I'm not sure how I would even
begin to participate in helping with documentation for something like a man
page if I wanted to. The actual creation of the man page itself, as I
understand it, is a single-user task. If you want community involvement to get
source material, you're going to have to have an accessible participatory
mechanism; a wiki, essentially, in whatever form that may take. But it should
be easy, no?

I suppose there's also the counter argument that "people who need wikis to
participate in something like git documentation are probably not the people we
want writing git documentation."

~~~
pjhyett
<http://book.git-scm.com/>

~~~
jrsims
Boom! That's a great site. Thanks for sharing.

------
Slambast
All this hg vs git, but no one remembers monotone (which had some influence on
git's development)

www.monotone.ca

Its a single file binary

Its supported on windows, linux, solaris and mac

has an interface for both scripts and users

Great documentation (and an easy to follow tutorial)

Interface is Stable

Single file to store the repo. I enjoy this b/c it makes backups extremely
easy.

Negatives are:

It may not be as fast as Git, but the difference is barely noticeable.

Pulling an initial repo from the master is slow when there are tens of
thousands of commits in the tree. After the initial pull, sync's between repos
are quick.

Diffs in MS Windows takes substantially longer than in linux.

Monotone may not be a perfect choice for the linux kernel, but its a great DVS
that's easy to use, stable and lets linux/mac/windows guys work together.

~~~
silentbicycle
And if you enable inode caching, it's _substantially_ faster. I wonder why
this isn't a default -- it seems like it is for hg and git, but people miss
the option in mtn and write it off as being slow.

------
lally_singh
Summary: neither is ready yet. Wait for one to get good enough to make the
other unnecessary.

My guess is Hg, as it's simpler. 90% of my SVN work is done with update,
checkout, and commit. Really, why so many more commands for essentially the
same work cycle?

Ok, that question wasn't rhetorical, I'm curious.

~~~
jon_dahl
I'd say they're both ready, and I've used them both for over a year now with
no problems.

 _My guess is Hg, as it's simpler. 90% of my SVN work is done with update,
checkout, and commit. Really, why so many more commands for essentially the
same work cycle?_

I prefer hg for just this reason. But unfortunately, it looks like git is
going to win. Why? <http://github.com>. Fortunately, they're both pretty good,
and so living with git isn't the end of the world.

~~~
maw
I agree that it looks like git is going to win, but for entirely different
reasons:

1) The person who wrote it is famous. It wouldn't have been taken seriously
had (almost) anyone else written something comparable.

2) Network effects apply strongly here. You can't just use something else if
you want to collaborate with people who use it.

I'm not very happy about having to use git, but the pain numbs after a while.
And, to be fair, it does have some cool features, although little-to-nothing
inherent to git or its implementation.

------
jrockway
_As such, the git project has consciously made no effort to make the migration
to git easy: the revert command in Subversion resets your current working copy
to the last commit, but in git undoes a supplied patch and commits the changes
needed to remove that patch. (The equivalent command for svn revert in git is
git reset --hard HEAD^.)_

Yes. You can't just make shit up and expect the computer to understand what
you mean. Last time I checked, git came with extensive documentation. Try
reading it :P

Anyway, I think hg takes the right approach to design -- a library that some
shell scripts call into. Git takes a non-ideal approach -- monolithic scripts
all written in different languages that sometimes share nothing. (Or more
often, call each other to "abstract away" some details.)

But despite this, git is much nicer to use. It's more flexible, more
consistent, and has a lot of really nice sugar. But I guess if you think svn
is the only way revision control can work, you won't like it. Your loss. <link
to "Beating the Averages">.

------
utx00
mercurial is one binary you say? well hg is basically just this:

from mercurial import demandimport; demandimport.enable()

import sys import mercurial.util import mercurial.dispatch

for fp in (sys.stdin, sys.stdout, sys.stderr): mercurial.util.set_binary(fp)

mercurial.dispatch.run()

....

that is a front end for this: ancestor.py demandimport.py hook.py mail.py
simplemerge.py util.py archival.py dirstate.py httprangereader.py manifest.py
sshrepo.py util_win32.py bundlerepo.py dispatch.py httprepo.py mdiff.py
sshserver.py verify.py byterange.py extensions.py i18n.py merge.py
statichttprepo.py __version__.py changegroup.py fancyopts.py ignore.py node.py
streamclone.py version.py changelog.py filelog.py __init__.py osutil.py
strutil.py cmdutil.py filemerge.py keepalive.py patch.py templatefilters.py
commands.py hbisect.py localrepo.py repair.py templater.py context.py help.py
lock.py repo.py transaction.py copies.py hg.py lsprof.py revlog.py ui.py

so what are you talking about?

~~~
silentbicycle
Apples to oranges. That's comparable to listing every source file in git.

How many of those do you ever execute directly? (How many are even in your
shell execution path?) All of the interaction with it is namespaced behind the
hg executable, including extensions.

~~~
utx00
what's the difference?

hg status -someflag | xargs do-something

git-status -someflag | xargs do-something

as far as usage is concerned -- is hg really less tool like? you're right, it
is partly semantics. however the article over-simplifies things to the point
of being misleading.

~~~
silentbicycle
One semantic/aesthetic difference is that git floods tab completion with all
the git- items, which is needlessly annoying. Namespacing the entire public
interface behind one executable feels cleaner.

I suspect the underlying reason people complain about this is that it's a
particularly visible instance of hg having a vastly cleaner public interface
than git. Of course, one person's "feeling cleaner" is another person's
"easier to write scripts/extensions for that won't break every time the public
interface to the relevant exposed internals change in the slightest way".
There seems to be much less effort to encapsulate the git interface for
consistent external usage.*

Some people will prefer git for just this reason, though: You can easily get
at the internals, if necessary. Like most of these "holy wars", it's a trade-
off, and different people have different values. Make an informed decision.
(Git's design values seem to resemble C's, while hg more closely fits
Python's. I strongly prefer the latter.)

* This is unsurprising, though: Linus has spoken rather condescendingly of monotone's "nice object-oriented libraries". (<http://lwn.net/Articles/249460/>) (He also complained that it was slow, though he caught it at a particularly bad time -- one of the lead developers had just gone on sabbatical (and was preparing to move across the country), and the issues causing the sluggishness were fixed shortly after.)

~~~
utx00
git is pretty good at dealing with lots of local branches. it has git-stash
which supports that even further (stash it now, come back to it later). it has
a staging area which allows you to slice and dice your commits. it seems to be
better and allowing you to rewrite the commit history.

i don't like git-repack, git-gc. i prefer the hg revlog approach.

hg can package all of its state from a given commit into what they call
bundles. git only has git-format. can git-format be as self-describing as a
bundle?

you can't delete named branches from mercurial. i say, so what. we have an
inactive branch. we merge uninteresting branches into there. hg branches -a
then shows you the unmerged (active) branches.

they're both good. it mostly depends on the way you and your team work.

~~~
silentbicycle
Agreed. I prefer hg overall, but I know it's more due to style than a clear
technical advantage one way or the other.

Is it possible to set branches -a to be the default in your hgrc, by the way?
(I was going to check on that this weekend.)

~~~
utx00
i don't think so no. you may have to go with a wrapper script or an alias.

do you know if it's possible to do bundles in git?

~~~
silentbicycle
Haven't tried, sorry.

It looks like you can add

    
    
      [defaults]
      branches = -a
    

to your hgrc to ignore inactive branches by default, though.

------
silentbicycle
Instead of arguing for one over the other, how about volunteering your time
and skills toward improving your favorite's weak areas? They're both quite
good, but there's always room for improvement. Give something back!

For example, if I have time this weekend, I'm going to work on adding support
for hg's record extension to its (already quite good, IMHO) Emacs interface.

------
davidw
Feels like a bike shed to me. The other %99 of the world is still using cvs or
subversion or something else, waiting to see what proves stable over a number
of years. Companies are going to thrive or fail depending on the products they
create, not the version control system they use.

~~~
LogicHoleFlaw
I could be doing a lot more creating at my company if I wasn't shackled to our
out-of-date version control system.

This is actually a serious issue which is finally getting traction to fix at
the management level.

~~~
davidw
> This is actually a serious issue which is finally getting traction to fix at
> the management level.

I'm guessing that 'version control' is just one symptom of other underlying
problems. I just don't buy that you're not creating a good product because of
version control.

~~~
LogicHoleFlaw
Oh, there are absolutely other problems. I'm not trying to pin all the
problems on CVS. It's just a major pain point which can actually be addressed
with a technological, rather than a cultural, solution.

The root problem is probably extreme conservatism coupled with an
unwillingness or inability to sensibly delegate responsibility, which adds up
to systemic paralysis when it comes to actually getting things done. It is not
a Hacker-friendly place. I'm fortunate enough to be in a small team which
manages to bypass a lot of the mess, but I'm still not sure how long I
actually want to stay here.

------
staticshock
_Despite that glaring flaw, the rest of hg is excellent. It functions almost
identically to Subversion in the commands that it shares, and the new concepts
- branching, merging, etc._

why exactly does the author refer to branching/merging as new concepts?

