Skip to main content

What's wrong with Hg? A philosophical discourse.

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


Popular posts from this blog

2017 Donations

Each year around Christmas I make a set of donations to causes and organisations that I want to support. I do this all at once, because I find I'm a lot more deliberate about what causes I support and the amount I want to donate than I am donating on impulse throughout the year.

I adopted this approach couple of years back after I read a tweet from Simon Lyall. Following his lead I've decided to blog my donations this year on the theory that it may encourage others in a similarly privileged position to do likewise.

I'm always rather uncomfortable discussing financial matters, so I'm going to avoid dollar amounts and just talk about groups of charities. Everyone's situation is different anyway so I don't believe dollar amounts really help the goal anyway.

Category 1: "Humanitarian Causes"

I use humanitarian loosely, my general preference is to support organisations working locally. I use GiveWell for supporting work overseas.

I split about 75% of my ov…

Planning, Estimating and Monitoring a Dev Project - Before Planning

Estimating and Planning and monitoring day to day development is a lot of what's involved in the job of a team leader. This is the approach I take to this, I don't claim to have created any of this, rather it's just the collection of agile methods and tools that I find useful. This is what I do for sprint planning every 2 to 3 weeks. When doing ball-park planning for a longer period I follow the same basic process but at a less granular level with corresponding drop in accuracy.

Before Planning There are a couple of questions that really need to be answered pre-planning. This is the side of planning that's often not visible to the juniors in the team. It's the bit that gets forgotten about and contributes to that wonderful "I don't know what my manager does, but when they're away it all goes bad" feeling in so many well run development teams.
The two questions you need to answer are How much time do you have?What are you trying to do? How Much Time D…

What is the first thing you do in the morning?

What is the first thing you do at work once you log into your computer? No really think about it, is it the same thing you were doing a year ago. I can almost track my career by the changes in what I do first thing in the morning.

When I was a junior developer, bright eyed and bushy tailed I checked my email first thing. It was a bit of a novelty to receive professional email and it made me feel a bit like an adult. Email seemed like the corporate information channel, so I thought as a responsible professional I should clear my email first thing and check it regularly during the day. The thing is though I didn't really get that much email as a junior.

As I started to become more senior I started to get more email. I also started to get more interruptions during the day. The morning started to be that really nice period where nobody talked to me. So I started to code first thing. Email could wait till I was being interrupted anyway. So my morning routine became code until I was int…