Transit of Mercurial

I’m quite fond of Mercurial, despite (though perhaps partly because of) using Git daily for the last ten years.

The first DVCS I used was Darcs, which I liked; then I tried Mercurial and liked it even more. That was 2007; I didn’t get my first job in a “Git shop” until 2010.

I’ve always found the Mercurial UX to be more pleasant than Git. Little things like invoking commands with unique left-substring, or seeing inbound or outbound commits with a single memorable command. Less operational complexity and fewer ways to shoot yourself in the foot, but with equivalent power.

Whereas Git’s pain points are so significant that somebody implemented a “Git-compatible version control system that is easy to learn and use” on top of it!

Git’s UI/UX have improved in recent years, but it still suffers from Too Many Ways to Do It, weirdly overloaded commands, and too many sharp edges. One critic observed that Git makes “no distinction between implementation detail and user interface.”

I also have some unease at the technical monoculture that has arisen around GitHub.

When Bitbucket – which at one time was notable for only supporting Mercurial – announced last year that they were dropping it, I started hunting for a new home for my Mercurial repos hosted there.

Beyond having current local clones of all of them, I wanted a project-hosting home for the active ones.

Options I considered:

• Self-hosting. Fun in theory, but I don’t want the system administration burden.
• “Just” convert all my Mercurial repos to Git. I did this for some legacy repos, but for the active ones it’s more of a surrender than a solution.
• Sourceforge. Not Dead Yet, and supports Mercurial. However, some of my repos are private; SF is open-source only.
• Helix TeamHub by Perforce. Supports Mercurial, and private repos, and has all the features. But after trying it out I found it just didn’t click; it felt kind of overbuilt and soulless.
• Heptapod, a fork of GitLab supporting Mercurial. This one is looking good now, with both a commercial offering and a FOSS-only instance. Unfortunately it hadn’t reached this stage back when I needed it, so I passed.
• Sourcehut. In public alpha, but stable and growing. Has private Mercurial repos and an issue tracker, the things I need the most. It’s an open source project, to boot.

In the end I chose Sourcehut and became a paid contributor. Looking over the list above, I’m glad there were so many options. When Bitbucket first made their announcement, it wasn’t looking so good. Now I’m buoyed by the number of engineers, projects, and companies who embrace a world outside of GitHub and a VCS tool other than Git.