I use Git everyday. I can't imagine using anything else. But I have a soft spot for Hg. For all the awesome power of Git it feels messy & complicated. Hg just feels like a cleaner model, a simpler transition, it's easier to explain and seems like it should just work. But for all that I find it gets in my way a lot more than Git. What's going on?

I initially started my dvcs journey using Hg. I was predisposed to Hg from reading Hg Init, which was the first time I really got dvcs. With Hg I found all the usual benefits of associated with a dcvs. The freedom of local commits, branching and local history. But for various reasons I gave Git a try, once I got my head around the way the different commands worked I really enjoyed Git. These days find I hard to use anything else.

But I can't put my finger on what is wrong with Hg. Perhaps it's just like wishing for the simpler times that never really were. Hg's insistence on immutable commits feels a bit purist and academic at times. After all, the first thing you need to do to use Hg as a super-client is to enable the rebase extension. In fact it seems that Hg is moving closer to Git all the time. Most of the git features for history editing are available as one mercurial extension or another. Cherry-picking, interactive rebase and amending commits all have equivalents.

Hg might dislike History Editing, but I suspect that these features are necessary to get the most out of your dvcs. Hg's approach of locking these off in extension has some benefit. You can understand the core functionality and then understand these more advanced features as manipulations of the DAG you already understand.

So I keep asking myself why it is that I find Hg so much more painful to use. I think it's actually just the relative maturity. I was going to write that Git has been around longer so had time to mature, but both Hg and Git had their initial release in April 2005, so that's not it. Of course it's not actually Hg that I find problematic it's the extensions I rely on day to day. Things like Subversion integration, rebasing, transplanting and history editing.

I think the real cause is that these extensions don't have the same focus and buy in from the community as in Git. I almost get the impression that they're looked down on. Histedit is perhaps the best example of this. It's a stunningly useful extension, basically giving us interactive rebase. Yet if you look at the Hg documentation of Editing History it's only mentioned as an after thought. The history editing solution distributed with Hg is MQ. MQ can do everything that Histedit can do, but it;s just so hard. The only reason I can see for making MQ the default and not bundling Histedit is to make history editing as hard as possible because it's philosophically distasteful.

This dislike of history editing does have real effects. For example Tortoise Hg has built in GUI support for MQ patch queues, but Histedit is relegated to the command line. I would think GUI histedit would be a real killer feature for a dvcs UI. I also find these extension just lack a little bit of polish compared to the Git alternatives. Rebase basically works like rebase but Git rebase is smother. Git rebase will identify that the commits are the same and just drop them, where as Hg rebase considers this a conflict.

There is no technical reason that the Hg extensions couldn't be as polished as their Git equivalents, but it hasn't happened. I believe this is because they are perceived as philosophically wrong by the Hg community as illustrated by the fact that they're not distributed with mercurial. I think this is a real shame, because I do like Hg, but it feels just a little to academically pure for the real world. Git is ugly, but it works with the ugly realities of the world.