I tried to love Mercurial

I previously mentioned I’ve been using git for twelve years. In the interest of checking what’s outside the current git-centric landscape, I spent six weeks using Mercurial.

I really tried to love it.

“There must be some way out of here”…

I decided to try it out on this repository (and a few others). I hit the first snag almost immediately: documentation on how to migrate git to mercurial is pretty hard to find. Every search engine I tried just returns results for… migrating mercurial to git.

Eventually I found the hg-convert extension. I gotta give it to the authors: it works swimmingly. Mapping the branches was a little mindbending, but I got there in the end.

And so, here I was, with a fresh repository, trying to write my first blog post under Mercurial…

…said the joker to the thief

I use IntelliJ Idea for almost all code-related tasks these days. Since this blog is, in large part, code - or at least semi-structured data - I write my blogposts in it, as well. I utilize the tasks feature to keep my work contexts separated. I used it to open a new task, creating the default changelist and branch.

Except it didn’t create a branch. It created a bookmark. Uh, what?

Branches in Mercurial are permanent. Especially if pushed to the server, then they’re really, really permanent. They can’t be deleted, except by really messing with the remote repository using certain extensions. These extensions are plastered with warning signs, too.

I forged ahead with my bookmarks, feeling like I’m at a library instead of at my desk. But it got me thinking: how do you collaborate with bookmarks? What if stuff diverges?

There’s a resource for that: Mercurial Kick Start. It’s really well put together, too. I understood what I was being told to do, I just didn’t like it one bit. I can kind of see how it would be used for trunk-based development:

• everybody works on their own repos and bookmarks,
• resyncs their repository periodically,
• pushes everything up to default - including bookmarks for code discussion,
• release officer creates/moves the release bookmark around, while leveraging tags to create release identifiers.

No joy for branch-based development though. Or my personal favourite flavor, branch-trunk-based-with-extra-toppings. Oh, and I squirm inside when I read stuff like There are no less than three heads!

Did I try to work with branches? Not really. Their persistent nature in Mercurial is a huge turn-off: I don’t like people seeing my mistakes publicly.

Speaking of…

“There’s too much confusion,”

Commits are persistent, too. Yes, you read that right: you pushed it up? Boom, your shame is on there forever.

When I’m working on a feature branch, I commit (too) early and (too) often. That’s just how I work. I don’t believe there is a single developer out there who has a plan right from the get-go for any feature longer than 100 lines of new code. And even if they did, maxim 17 states: “the longer everything goes according to plan, the bigger the impending disaster”.

“Disaster” is, then, the typical state of my branches before they are published. When they are, they’re split into logical pieces in separate commits, free of (some) bugs and with pristine, thoughtful comment messages.¹ I achieve this via incessant rebasing, of course.

So, how does one rebase in Mercurial? Assuming their commits were never public, and are therefore in the secret or draft phases? If you said rebase extension, bzzzt! wrong. Rebase is for reordering commits, you silly goose.

You could achieve a similar effect to git’s rebase with changeset evolution, though that’s plastered with even more warnings than git’s². I gave up before I got too deep into that particular rabbit hole.

“I can’t get no relief”

I’ll admit that my way of thinking about SCMs is very much colored by git. Unfortunately all the git-like features of Mercurial are just different enough that it didn’t click with me at all through these six weeks. I tried to love it; maybe it’s too late for me.

I guess for now I’ll begrudgingly trundle back to the git-centric world, where I at least understand how to get stuff done.