Mercurial, 20 years and counting: how are we still alive and kicking? [video]

https://fosdem.org/2026/schedule/event/AGWUVH-mercurial-aint-you-dead-yet/

by ibobev • 2 months ago

213 252 2 months ago

fosdem.org

srean• 2 months ago

I am glad the Hginit is back https://hginit.github.io/index.html

Not sure why it has to disappear in the first place.

What's going on with hginit.com now ?

macro-b• 2 months ago

At my previous big tech employer we used to have a mercurial layer on top of our legacy version control system. I loved it, much simpler and more clear than the typical workflows I have to deal with in git. I get it that with git you have more power, but do really most teams need that?

KwanEsq• 2 months ago

Do you actually even have more power with git?

g-b-r• 2 months ago

No, it's the opposite

12_throw_away• 2 months ago

Unless git has some hidden way to do changeset evolution (maybe with jujutsu on top?) then no - I'm pretty sure git is strictly less powerful than hg these days.

juvoly2• 2 months ago

Mercurial wasn't as simple as Subversion. But with hg I still felt like understanding 80% of what the tool had to offer and actually being able to mold the timeline the way I wanted.

Git has so many gotchas, bells and whistles that whenever I'm doing something out of the ordinary I'm wondering if there isn't an easier / canonical / smarter way I should be doing it.

mark_undoio• 2 months ago

There was a quote somewhere about Mercurial having a mental model small enough you can fit in your head - and that was the big win for me.

It was also fast and had very clean, easy to contribute to code. I remember submitting a patch and getting a bit of Python education from Matt, which was very useful.

Git is fine but it's inconsistent enough in the interface department, even after all this time, that I still get regularly frustrated. On the other hand, you can't just break a workflow that already exists and I very much appreciate it scales to work far beyond mine.

I do like that the git people are doing the difficult work of improving the UI over time - it's hard to change the engines while the plane is flying!

tasuki• 2 months ago

Mercurial wasn't as simple as Subversion.

What? Subversion is by far the most complex versioning software I've ever used.

Git has so many gotchas, bells and whistles

The Git UI leaves a little to be desired. But inside, Git is basically just blobs, trees, commits, and refs. It'd be hard (or impossible?) to find a conceptually simpler versioning system.

Espressosaurus2• 2 months ago

Git doesn't give you more power, it just makes their internals your problem.

zabzonk2• 2 months ago

I loved Mercurial - still do I guess as I just installed it on the Linux Mint VM I keep around for messing with Linux. The thing I really liked about it was TortoiseHg, which provides integration between Mercurial and Windows Explorer. There is a similar TortoiseGit but, at least back when I was doing serious development, it had quite a few problems.

Pay08• 2 months ago

FWIW, as a recent user of TortoiseGit, it seems pretty decent nowadays.

zabzonk2• 2 months ago

That's what I expected - I was sure the Tortoise guys would get it right eventually.

PathOfEclipse• 2 months ago

Almost 20 years ago I helped our company choose between Git and Mercurial as the replacement for Subversion. Unfortunately, I helped them make the wrong choice, Mercurial.

I say wrong because clearly Git won the war and I haven't used Mercurial since then. However, I still think I made the right choice from a technical perspective; I thought Mercurial was way more user-friendly while providing all the features and performance needed. But I guess I couldn't read the future in terms of which one would win out!

woadwarrior01• 2 months ago

I'd made the exact same choice around the same time at the company where I was working. Last I heard, they're still using it. My rationale was that Mercurial was a lot safer and user-friendly compared to git. Needless to say, git has improved by leaps and bounds since then.

avarun• 2 months ago

Around 20 years ago Facebook made the same choice, so you're in good company in terms of technically sophisticated shops.

loeg9• 2 months ago

Facebook has been using their own in-house Sapling/Eden for years and years now. I'm not sure how much similarity remains with open source Mercurial.

zeroonetwothree3• 2 months ago

Facebook didn’t adopt mercurial until something like 2014? And before that used svn -> git

tempest_• 2 months ago

Our company also made this choice.

One of the first things I did was switch us to git.

Mercurial was way easier to use and fit our use case but all the tooling was built for git.

amluto4• 2 months ago

I also did this. Both in hindsight and at the time, I thought Mercurial had far better tooling. But it was not all amazing: Mercurial’s branching model was very poor, and its sequentially numbered revision system was and remains a very bad design.

locknitpicker3• 2 months ago

I also did this. Both in hindsight and at the time, I thought Mercurial had far better tooling.

I recall checking Mercurial back in the day and being puzzled by the lack of basic features such as the ability to stash changes. I also recalled that the community was dismissive of the lack of such a basic feature, with comments such as users could always create local branches, of even we could perhaps install a module such as shelve.

That was the image that Mercurial left with me with regards to git: missing critical features and not bothering to bridge the gap.

rileymat22• 2 months ago

I think I liked the Mercurial branching model better than git, due to the branches being a first class record of events. What I did not know is how common the git rebase/clean linear history would become or a desire to change history on merge.

Mercurial had bookmarks that were roughly the same as git branches.

The linear version numbers were quite useful to reason about and use in places that call for a "number" version number, and were useful relative to your "master" clone. That was not the primary way though, it had hashes like git too, that were the same from clone to clone.

deepsun• 2 months ago

Sequentially numbered versions is still used at main Google monorepo (at least did a few years ago), named "changelist number", from perforce. Up to the point that people define extension field numbers in protobufs using their changelist number, to ensure it will never intersect with anyone else.

somewhatgoated2• 2 months ago

I always hear it has far better “tooling” but then the comments say that branching sucks, revisions suck and there is no good got stash equivalent - this is like a third of what I use daily with git.

What does “far better tooling” mean exactly, could you give an example of what amazing tools I’m missing out on (never have used anything else but git, when I came to the industry it was already the standard)

justsomehnguy• 2 months ago

You did the right at the right time, you wasn't some prescient being. Why are you

3form• 2 months ago

I'm glad that I stuck to git for a similar reason; it won the war. And I understand the need for simpler tools.

But to offer a point I haven't heard from anyone before: at least I feel that I am done with it, I learned this tool sufficiently and I can move on with my life. From time to time I add something to my git toolbelt. I feel if Mercurial or anything else have won, I would maybe have to learn another tool in 5 years, whatever else got popular, and another in next 5 years. But now I have everything I need in git, and always have needed. I hold some hope in it that perhaps the learning curve was worth it.

MBCook3• 2 months ago

That’s a great point I hadn’t thought of before.

I’m glad there is one clear winner and we’re not in the common position of having 2-3 relevant/semi-relevant choices that you’re frequently asked to switch between depending on which project you’re looking at at the moment.

Git is modern version control, whatever you think of it, and there’s a simplicity to that.

esafak• 2 months ago

Despite not using anything else, I don't know all the git commands I need to get my job done so I use UIs and my agent. It's just not intuitive enough, some things are just not possible to do right, and I look forward to ditching it.

qwery• 2 months ago

I don't think Git winning a popularity contest is a reason for choosing Mercurial to have been wrong, or unfortunate. Was there some negative consequence from the decision -- either directly from Mercurial itself, or just because over time everyone expected Git, perhaps?

(Hopefully this comes across as curious, which it is, and not antagonistic, which its not)

MBCook3• 2 months ago

Not GP but there is a consequence. These days if someone has used version control they almost certainly know Git.

That means pretty much everyone who comes in the door needs Mercurial training, whether formal or informal. You’d get the same effect from still using CVS, SVN, or other things.

That may not be a big issue. If someone understands version control I’d hope they could adapt to another minder pretty fast.

It’s still an issue. There is technically a cost.

yegle• 2 months ago

I have the feeling that Git winning the war hinges heavily on GitHub being the way to do open source projects, and that is changing given the sad state of GitHub.

Another contender is Jujutsu (jj) which allows you to use jj as frontend and use Git as the backend (with the potential to support any backend, e.g. Google's proprietary Piper), with the best ergonomic and the widest availability of hosting solutions.

ncphillips• 2 months ago

I’ve recently switched to jj and it is truly amazing. It too about a week for me to “get it”. The tool is amazing but I think there’s way too much emphasis on what it does/allows rather than what benefits it brings to your workflow. If they get that marketing right I could see it growing. If not, I’ll keep using it

lmm• 2 months ago

I have the feeling that Git winning the war hinges heavily on GitHub being the way to do open source projects

Nah. At the time BitBucket was the better way to do open source projects, and they were Mercurial-first. But eventually they had to add Git support because there was so much demand.

jjav2• 2 months ago

Mercurial is one of the many sad stories of far better technology being forgotten by the popularity contest juggernaut of something else.

I still use mercurial for all my personal project where I don't need to care what anyone else thinks. It is pleasant to use good tools, just like I like to buy top quality rachets or such.

loeg9• 2 months ago

Mercurial wasn't the better technology, though. The UX is almost the same as git, diverging in ways that are arguably worse, but the tools were written in much slower Python (initially, and for many years after).

smartmic• 2 months ago

Can't comment on Mercurial, but "for all my personal project where I don't need to care what anyone else thinks" I am using Fossil. Ever since that decision, I've felt a bit, well, held back, or rather, I don't feel quite as comfortable as I do at home when I have to use Git.

F3nd0• 2 months ago

And in a similar vein, Darcs. It unfortunately couldn’t compete with Git on performance, but the user experience is on a whole another level.

nezi• 2 months ago

Is git really far worse technology than mercurial? I’ve used both for years and to be honest they are pretty similar. What important capabilities does hg have that git does not? Maybe you can argue that hg is more ergonomic, but that’s just polish it doesn’t mean the tech is far better…

aidenn0• 2 months ago

My recollection is that it was more of a VHS vs Betamax story than one being strictly superior. When a lot of people were making their decisions, Git was a lot faster in ways that mattered. IIRC, shortly after a lot of places picked Git, Mercurial cut a release that significantly improved performance.

pitkali7• 2 months ago

Mercurial had an easier to use command line interface. If that's what makes it far better technology, we have a very different idea what makes the "technology" better.

fHr• 2 months ago

meanwhile my org still uses svn for a lot of repos at least my teams are full git...ugh

martin-t2• 2 months ago

I hate that social factors like popularity are a thing in technical decisions.

I have not used mercurial (though heard good things about it) but I saw a similar thing play out in Rust gamedev. There are 2 competing game engines, one better technically, the other much more popular. Now, if everyone made a purely technical decision, they'd pick the first one and eventually it would become the more popular one. Unfortunately, whenever I asked people why they chose the second one, they said because it was more popular. Tragedy of the commons.

If it's any consolation, maybe jj will take over. I haven't tried it yet (I use the staging area a lot in my workflow), but AFAIK they made the choice to be git-compatible which means it's not a choice between one or the other but lets people and teams migrate gradually.

Shish2k2• 2 months ago

FWIW you can still have a staging-area-like workflow with JJ - it's just that while git has "commits", "the staging area", "the working directory", and "stashes" as four separate concepts with four separate toolkits, in JJ all of those things are "commits" and a single toolkit works with all of them :)

HWR_14• 2 months ago

Tragedy of the commons

That's a different concept. You are describing network effects.

foresto• 2 months ago

I helped them make the wrong choice, Mercurial.

20 years ago, Mercurial was not the wrong choice.

- Its internal design was very similar to Git's.

- Its cross-platform support was superior to Git's. (Git didn't get good Windows support until some years later.)

- Its ergonomics were superior to Git's, which was an important factor on its own, and especially important when trying to get a whole organization to retrain and retool around a distributed model.

- (It had a third major advantage over Git that I unfortunately cannot recall at the moment.)

So you weren't wrong back then...

...but Git improved over time, tipping the scale closer to a balanced state. It also had unbeatable author recognition, making it the obvious choice for anyone unaware of Mercurial's advantages, and eventually leading it to benefit from the network effect. And GitHub appeared, greatly improving Git's ecosystem with no support for Mercurial.

ciupicri4• 2 months ago

I don't know what you mean by ergonomics, but I remember trying both Mercurial and Git back in the days after using Subversion before. I didn't like how Mercurial didn't easily let me rewrite history and do stuff like `git commit --ammend` or `git rebase`. Mercurial users kept telling me using an extension to manage patches on top of Mercurial (I think it was quilt).

I agree about the Windows support. hg serve was also nice. Plus TortoiseHg.

JoshTriplett• 2 months ago

Its ergonomics were superior to Git's

That's a matter of taste. I used both for serious work, at the time, and found Git much more usable. My experience with Mercurial was "welcome to Mercurial, how can we help you merge and push your work in progress even though that's not what you want?" My experience with Git was one where I felt in control at all times, had a clear workflow for when I did and didn't want to publish my changes (and for when I wanted to edit them first), and allowed me to quickly make and switch branches within a single working copy.

pitkali7• 2 months ago

I don't think the internal design is/was that similar. We switched from CVS to git, and were evaluating multiple choices. What tipped the scale in the end was our trust in the internal data model, which for git was the idea that it stores the snapshots, and they are immutable. The diffs you can get out of it are calculated on demand. Even if on-disk storage can end up using some diffs to save on space, the actual conceptual model of every operation is based on those snapshots, and that is also how every new commit is stored before repacking the repository.

This appealed greatly to us, and always meant that it is effortless to undo any operation because it only creates new snapshots, while the previous ones stay there for a while in case you need to recover the previous state.

This is in contrast with Mercurial, where the data store is (was?) a sequence of diffs, and then the state of the working tree at any time is reconstructed on demand from those diffs.

dismalaf• 2 months ago

I used Mercurial back in the day too. I agree, it was better. That being said, GitHub was better than other similar services which no doubt helped git win and now, git is ubiquitous.

sampo• 2 months ago

But I guess I couldn't read the future in terms of which one would win out!

After Linus Torvalds gave this talk at Google in 2007, it was clear he would win. (Is there a better quality video somewhere?)

https://www.youtube.com/watch?v=idLyobOhtO4

But I agree: Mercurial was definitely friendlier for people who didn't have time time to go through the technicalities of git. To use git smoothly you pretty much need to learn how it works internally.

PunchyHamster• 2 months ago

To be entirely fair nothing in git backend prevents someone to make friendlier frontend.

squirrellous• 2 months ago

Both Facebook and Google internally use a custom version of mercurial, so I wouldn’t count it out just yet.

vogelke• 2 months ago

Best part about open source -- Mercurial is still around, I use it for my home servers, and it's being maintained. I can use git, but Mercurial's workflow just makes more sense to me.

gora_mohanty• 2 months ago

Heh! Are you me?

Echo your comments: Mercurial seemed more logical, and had one way of doing things. Have gone over to git, but still need to search for the command that I need.

ezst3• 2 months ago

Then you made the right choice, and it's only unfortunate that not enough of you made the same to tip the scales in favour of mercurial, or at least to avoid the monopolistic situation we are in now.

I might say that I stopped thinking too hard about this many years ago: now I use hg-git whenever I must interact with git, but do regret that the more sophisticated/qol features of hg (branches, evolve, phases, topics, ...) don't exist in git, and that's the real bummer: the more limiting alternative won, then stagnated, and we are all worse off as a result.

idank• 2 months ago

Anyone know what Matt Mackall is up to these days? He started Mercurial and got people involved early on with a lot of enthusiasm, you could tell he cared about what he created and the people who joined him ("hg crew"). I learned a lot from him on how to think like an engineer and saw him manage different personalities in the project in a kind and sincere way (I think this was around ~2010).

interroboink2• 2 months ago

FYI: Matt Mackall is now Olivia Mackall [1], so that can make searching for things harder. Looks like they work at Valve, now? Agreed that they were a really stabilizing and healthy personality in the project, and made a lot of good early decisions, which Mercurial has continually benefited from. Eg: the commitment to backwards-compatibility [2].

[1] https://repo.mercurial-scm.org/hg-stable/rev/d4ba4d51f85f

[2] https://wiki.mercurial-scm.org/CompatibilityRules

sunshowers• 2 months ago

Olivia uses she/her, and I believe she is now retired :)

I owe her and the Mercurial community a great debt. The community taught me how to think like an engineer building infrastructure and the importance of backwards compatibility, something I've tried to carry forward in tools like cargo-nextest.

tonfa• 2 months ago

+1 I learned so much about software engineering (Software design, network protocol incl how to handle backward compat in sane ways, ...) thanks to the mercurial community.

chiph• 2 months ago

I just installed it on a Raspberry Pi (with an otherwise too-small-for-any-other purpose SSD) for use at home. I wanted something with low power consumption, and I didn't want to have a single point of failure by running it in a container alongside everything else.

The only hiccup was forgetting that when pushing via the SSH connection, it will have paths relative to the home directory of my hg user.

ssttoo• 2 months ago

IIRC Facebook switched to HG from SVN in the 2010s, one (main?) motivator being that the single repo was getting too big and svn’s only way was to start splitting it up. Which was against the philosophy of openness of the single repo. No idea what’s Meta doing now.

Shish2k2• 2 months ago

Last I checked (2 years ago) Meta was using Sapling, a very heavily customised open source Mercurial frontend with proprietary backend.

FWIW the Sapling frontend can also be connected to a Git backend, and I've been using that for all my open source projects to get the best of Mercurial's user experience niceness while collaborating via GitHub <3

loeg9• 2 months ago

Still Sapling + Eden to make local work on a sparse checkout viable.

rileymat22• 2 months ago

In my time with it, about ~20 years ago, it had a lot of nice features for instance hg came with a web server/interface out of the box.

ciupicri4• 2 months ago

I liked too. It was `hg serve` [1]. Instant web interface and an easy way to share the repository with other people (assuming your computer was accessible from the LAN or Internet).

[1] https://mercurial-scm.org/help/commands/serve

TLLtchvL8KZ• 2 months ago

I haven't used hg in years now, bitbucket discontinuing support is what killed it for me and I had no interest in self hosting.

My git usage is very basic, my gitconfig has been pretty much untouched for years but on those occasions where I get stuck or hit something I end up searching and usually get through a bunch of posts/comments/sites and wish I was using hg.

DavidCanHelp• 2 months ago

jmole• 2 months ago

hg (fig) was definitely my favorite frontend for source control at google.

Zopieux• 2 months ago

I sincerely hope jj gets the recognition it deserves in coming years.

t435624• 2 months ago

Mercurial was safer and better. I still use it and it's still safer.

The bookmarks feature which is supposed to be the solution for short-lived branches is hard to understand though. I'm probably dumb but I can't work it out and hence the overall tool is that much less useful.

It needs a github-like website and Heptapod would be great if I could use it - I've set up a project, been unable to do anything and then had it all closed down. OTOH self-hosting is a lot more feasible nowadays with today's fibre connections.

ciupicri4• 2 months ago

I hated so much how Mercurial dealt with short-lived branches, that after seeing how Git did it, I've never looked back. I also remember how some people told me to use the quilt or something extension to manage patches, but it was too complicated for me.

seany• 2 months ago

It make a lot of sense if you think of repo history as properly immutable, and dispose of the notion that brach is a first class object in the git sense. Bookmakers just pin a checkin hash to a name, and you can have many heads in an hg branch.

irishcoffee3• 2 months ago

What does short lives branches even mean? Make a branch, close it, or merge it.

ezst3• 2 months ago

The bookmarks feature which is supposed to be the solution for short-lived branches is hard to understand though.

yup, it came up as a response to git and people getting more and more re-wired into thinking of "branches as pointers", with its own bag of implicit state and behaviour. No wonder it felt clunky and unpolished used in this context. That said, it was a pretty effective way to globally distribute a namespace of string→commitID pairs, i.e. a list of commit bookmarks, and at least in that sense the feature wasn't a total misnomer/let-down :-)

forrestthewoods• 2 months ago

Mercurial is just better than Git. But GitHub won and so Git won.

mnahkies• 2 months ago

My first full time job after university was using hg, and particularly https://tortoisehg.bitbucket.io/ made it really pleasant.

Prior and post that I'd always used git but I'll always have a bit of a soft spot for mercurial, especially as our forge usage at the time predated strict guardrails and controls - we did code review, but it was your responsibility to tag the appropriate people and wait for them to respond, if you felt it was necessary to merge prior to that you could - but better be ready to defend that decision.

jgalt212• 2 months ago

Our shop uses Mercurial, and I hop we never move to Git, but I do see us eventually moving to whatever is next.

BeetleB6• 2 months ago

I always preferred Mercurial to Git, but now that Jujutsu is out there, I think Mercurial's demise is all but guaranteed.

If there were a reliable way to use Mercurial on a Git repository, it could live. But why bother when one can use Jujutsu?

kccqzy6• 2 months ago

Jujutsu took the best parts about mercurial and enabled these to be used with git and git forges. Once I had gotten used to jujutsu I didn’t really miss mercurial.

holoduke• 2 months ago

Just a bit off topic. But is anyone still using git or whatever versioning in the traditional way? I hardly see myself using the git command these days. Everything I handled by Claude. From pulling to pushing to solve merge conflicts and more. In a way it doesn't matter anymore whether it's git or something else.

qa3-tech• 2 months ago

Glad it is still around. hg was the better experience as it had fewer command surface. But slower, and sometimes you need the extra detail commands to analyze the history.

kgk9000• 2 months ago

Git likely won because of GitHub; I abandoned Mercurial quite early when it was clear that it had lost. It was good, but I cannot imagine using it today.

jedberg• 2 months ago

We used Mercurial at reddit. We switched to it shortly after switching to Python as our main language, figuring it would be easier to use the one written in Python.

We used Mercurial until the day we went open source. We actually preferred it, but we knew at that point that "everyone" used Git, and we would never be seen as serious or get user contributions unless we switched. That was back in 2008. [0]

We actually self hosted a ticketing system[1] and our own git repo, but since the system we used didn't have pull requests, we had to use the old school method of sending us a patch via mailing list using the git-send-email command, the same way the linux kernel did it.

The best part of this is that we had a launch party for open sourcing in San Francisco. The date of the party was chosen a few months in advance, because it takes that long to plan something in physical meat space. This was basically the first time reddit ever had a hard deadline to get something done.

I was primarily responsible for setting up the ticketing system and code repo, and at the same time, we were switching our actual servers to pull from our public code repo for deployment, for true transparency (and I had to set all that up too).

I actually had to do the final setup to make everything public sitting at the bar at the venue with my laptop about five minutes before we opened the doors. At the time, I had about a week of experience with git! And here I was, operating what was expected to be a very popular open repo that anyone could clone from. Good times.

[0] https://web.archive.org/web/20080619043654/http://blog.reddi...

[1] https://web.archive.org/web/20080622134154/http://code.reddi...

bombcar• 2 months ago

I still wish bzr had had a better showing.

throwatdem12311• 2 months ago

How is the rust rewrite going?

SonnyTark• 2 months ago

I hung on to hg all the way until bitbucket forced migration to git. I still dislike git, but I dislike perforce much more.

I guess I just wanted to say I hate perforce lol

7e• 2 months ago

Mercurial is so, so slow. It is painful to use.

irishcoffee3• 2 months ago

I should write a whole article about this.

Hg is a superior tool compared to git. It logically just clicks, for everyone. Changesets, branching, merging, tagging, it all just works.

Git is this arcane blob of whatever-you-call-it where rewriting/erasing history is not only allowed, its encouraged. That is insane to me.

Git is a fine tool, it is in every possible way inferior to hg.

pitkali7• 2 months ago

I never got the idea from git itself that changing history is encouraged. What makes you say otherwise?

irishcoffee3• 2 months ago

git rebase

Is a widely accepted command as a daily part of a development workflow. This command rewrites history.

eeeficus• 2 months ago

Unpopular opinion: Git is better than Mercurial and people just make a big fuss when you refuse to play with their toys!

garganzol• 2 months ago

We support Mercurial project financially and we use it everyday. While I use Git for hobby projects, it does not cut it in terms of ease of use. Some newer SCM systems like jj look promising, but absence of tools like TortoiseHg undermines their possible adoption.

Mercurial, 20 years and counting: how are we still alive and kicking? [video]

Related Stories