Published: Sat 18 June 2011
In Rants .
tags: git hg source-control
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.
There are comments .