My view on Mercurial versus Git

June 3, 2012

I've kind of alluded to my views in passing before but since I've already written a certain amount on these two systems (and a chunk of it sort of in favour of Mercurial) I feel like writing about this explicitly, just to be clear.

(You should insert implicit 'in my view' disclaimers in the following if desired.)

For my own use, Mercurial is easier to start with and use simply, more user friendly, and more 'humane' (in that in general it works more how people expect). However, Git is technically better, more powerful and complex, and is more willing to be pragmatic and useful. Mercurial people (at least in my perceptions) are still somewhat tied to the 'proper' VCS way to do things; Git people are much more flexible and willing to compromise in order to do the 'impure' but right thing (the primary exhibit of this is git rebase). Git's drawback is that it has far more exposed complexity than Mercurial does; you cannot really learn or use Git without understanding things like the index, the (abstracted) repository format, and so on. But once you do, the good news is that everything makes sense.

(Saying that Git is technically better may irritate people, but I do feel that it's true. Over and over I've found myself persuaded that Git makes the right fundamental choices on things like repository formats, whether or not to try to track file renames, and so on. I don't currently know enough to have an opinion in the great debate over Mercurial branches versus Git branches.)

The net result is that these days I like Git more and it's what I'm focusing on. Mercurial is okay and I know enough about it to get by, but I would rather use Git for future repos and spend my time learning more about it. This marks a change of my mind from how I was a few years ago (when I found Git intimidating and Mercurial nicely easy), but I figure I'm allowed to do that. I know that there will be a learning curve and some frustrations in using Git, but I'm okay with that; I think that it will be worth it in the end.

(Things for work will continue to be in Mercurial repos, because that's our standard for good reasons.)

As a side note, I would say that Git's flaw is that it has never been willing to compromise or hide its complexity in order to present people with an interface that feels simple and natural. There have been attempts to do so every so often, but as far as I can tell they've never really caught on (and I don't think they've had enabling support from the Git core). The result is a powerful but complex and deep interface that doesn't necessarily operate the way that people start out expecting. This is why I say that Mercurial is more humane than Git; Mercurial has made an effort to have its interface operate in such a simple and natural way, even if it means not offering a certain amount of power to people or hiding it.

Sidebar: the pragmatic perspective

On a pragmatic basis Git has won. I say this for one simple reason: Github. If you work with open source projects (even just using them) you will sooner or later wind up dealing with Github. And if you want to share or show people your open source code, even trivial code, Github is again the platform that people will want you to use.

(Yes, there is a Mercurial equivalent, but Github is far bigger and far more dominant. And yes I believe that you can use Mercurial with a Mercurial to Git bridge to interact with Github if you're stubborn enough and really want to, but let's be honest; you're making life harder for yourself.)

Honesty compels me to admit that this was one large reason I finally started putting things into Git repos; I wanted to put them up on Github, so it was time to get serious about using Git.

Written on 03 June 2012.
« Some things that strike me about Linux and UEFI secure booting
Another view of the merge versus rebase debate in version control »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jun 3 02:29:16 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.