Git vs. Mercurial: Please Relax

http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/

by Anon84 • 18 years ago

48 32 18 years ago

importantshock.wordpress.com

utx004• 18 years ago

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?

silentbicycle6• 18 years ago

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.

utx004• 18 years ago

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.

jrockway• 18 years ago

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">.

ajross• 18 years ago

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.

aaronblohowiak• 18 years ago

Like the constitution.. it is written on parchment! Parchment! How terrible. You can't search it or handle it with your bare hands.

That being said, it is easier to update a wiki than to get a man page updated. This may foster better or more documentation, but ultimately the format does not dictate the utility.

jrsims2• 18 years ago

...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• 18 years ago

http://book.git-scm.com/

gcv• 18 years ago

Well put. I'm appalled that people keep promulgating this FUD about git documentation. Git's User Manual (http://www.kernel.org/pub/software/scm/git/docs/user-manual....) is the first hit on Google for "git manual". From my reading, it's roughly equivalent to the much-lauded Mercurial book.

The author then writes: "I installed git through MacPorts, only the main git tool comes with a man page, leaving me to consult the Web to find out exactly how to format revision specifiers." He did not seem to realize that the git-core port has a nifty variant "+doc", which installs full documentation, including the aforementioned manual.

silentbicycle6• 18 years ago

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.

lally_singh• 18 years ago

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.

DarkShikari2• 18 years ago

I use git, so I'll explain a few things I like about it.

1. I can commit things locally before committing them to the main repository. This allows me to commit something in a manner that separates it from all future changes, but test it for a few more days in future development before I actually push it to the main repository.

2. I can correct past commits. This means I don't have to clutter up the history with "fix typo"; I can just amend the previous commit. Obviously this isn't useful for stuff far back, but if I commit something and 2 minutes later someone points out a typo, I can fix it. A messy history makes development and bugfinding harder; git helps avoid it.

3. Git diff is formatted a bit more nicely than svn diff, IMO.

holygoat• 18 years ago

I hate to point out the painfully obvious, but the discussion in this article isn't about why one should use a DVCS, but about the respective pros and cons of Git and Mercurial.

Your comment is a little like saying "man, a visual text editor sure beats using ex on a teletype!" in the middle of a vi/emacs war.

jon_dahl• 18 years ago

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• 18 years ago

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.

icky• 18 years ago

I prefer git because my work uses SVN, and nobody needs to know I'm using git-svn.

Add git rebase -i into the mix, and I can wrap up all my externally-uncommitted changes into one perfect changeset.

davidw2• 18 years ago

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.

LogicHoleFlaw3• 18 years ago

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.

thorax• 18 years ago

What version control system are you using?

davidw2• 18 years ago

> 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.

Slambast• 18 years ago

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.

silentbicycle6• 18 years ago

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.

staticshock• 18 years ago

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?

Git vs. Mercurial: Please Relax

Related Stories