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!
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...
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.
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.
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.
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.
Not sure why it has to disappear in the first place.
What's going on with hginit.com now ?
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.
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.
Python developers, especially core are used to perpetually broken software and don't like stuff that just works. As long as the software is in Python - C (git) and Ruby (websites that used to work at that time) are fine.
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.
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.
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
The Mercurial CLI has clear, well named commands that are predictable and easy to memorize. hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively.
The Git CLI requires you to understand its internal data structures to understand the difference between a rebase and a merge, and most people still can't explain it.
I've worked with Mercurial for 5+ years and no one on my team has ever given up on a client and done rm -rf to start anew. Every single git user I've talked to has done that multiple times.
It was a much less stressful tool to use and git hasn't really got much better since then - I've just converted a repo to git and the team using it have had about 4 unpleasant mistakes in the last week as they adapt.
As for speed.....I cannot say I ever noticed any problem. Waiting around for the version control system has never been an issue for me.......except a git repo with 70,000 commits and we worked out how to merge a lot of those to fix the problem.
One of the big criticisms I've seen levied against Rust is that refactoring is extremely difficult, so prototyping on ideas in the language itself is a poor experience.
I've personally had great success using python, then gradually rewriting the tool I have with py03 to "oxidise" the program iteratively.
Starting with C was great for performance of Git, but damn if it's not a terrible UX these days, I can believe that the choice of toolchain and language was a contributor to that fact.
In contrast every single mercurial user I know can intuitively use `hg rebase` with its `-s` and `-d` flags. That’s one giant difference in UX.
I've used git and mercurial for roughly the same amount of time.
Your statement is, frankly, something that makes me question your sanity. They're not remotely similar. Outside of something like Perforce, I've not used a VCS with a worse UI.
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.
If there were a reliable way to use Mercurial on a Git repository, it could live. But why bother when one can use Jujutsu?
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.
[1] https://repo.mercurial-scm.org/hg-stable/rev/d4ba4d51f85f
(Hopefully this comes across as curious, which it is, and not antagonistic, which its not)
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.
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.
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.
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.
The core concept is similar -- history is a stream of content-addressed commits. Concepts map almost 1:1. git does some things arguably better.
> hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively.
hg histedit is basically identical to git rebase -i. The names are different, but the operations end up being more or less the same. hg amend -> git commit --amend. Graft -> cherry-pick.
> I've worked with Mercurial for 5+ years and no one on my team has ever given up on a client and done rm -rf to start anew. Every single git user I've talked to has done that multiple times.
I don't know what to tell you. I've also worked with Mercurial for 5+ years, but I've never rm -rf'd a git repo.
I don't know anything about mercurial, but is it really too much to ask of software engineers to understand a DAG (the only "internal data structure" in question)?
About rm -rf ing a repo, I'm sure if mercurial was more popular it would also suffer from the types of coders that would do such things on a regular basis.
With any other system, your only option is usually checking out a fresh copy from a server or backup.
Isn't the entire git rebase logic written in Bash scripts? Or was originally?
This fallacy again. Tell me, when did Mercurial decide "ok the prototype is done, we'll rewrite it in a proper language"?
They didn't, of course. Because nobody ever does. Your "prototype" gradually becomes a 100k line product that you can't afford to rewrite.
(I guess you can YOLO it with AI these days but that wasn't an option for Mercurial.)
> Starting with C was great for performance of Git, but damn if it's not a terrible UX these days
Git's terrible UX doesn't have anything to do with C. C doesn't make you always pick a different flag for "delete".
...than git? than hg?
I agree about the Windows support. hg serve was also nice. Plus TortoiseHg.
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.
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.
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.
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)
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!
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.
If git doesn't let you do them "right", your concept if "right" is wrong.
People always say you have to know git internals in order to use it, but that's just not true. Git has the right data model and has always been about empowering users to edit their data. Which makes the data model be "in your face" compared to the alternatives (and I think that's what people latch on to when they talk about "internals"), but it ultimately makes for a better tool.
And then, when you pull someone else’s in-progress work to inspect it, you end up with their branches showing up with their names and you ended up with revisions 13564-13592 belonging to someone else and showing up in your history graph even when you continue on your own work at revisions 13563 and 13593. I ended up using temporary clones and strip a lot.
git branches, in contrast, are delightfully unobtrusive.
I started with Mercurial, eventually got forced into git, and now use jujutsu.
Totally agree with the Mercurial developers: Just use a branch/bookmark. When I encountered it in git, it seemed neat, but became yet another concept/thing to clean up that you don't need to.
And lo and behold, after switching to jujutsu, everyone shows how you can do a stash using an (anonymous) branch.
Even though I used stash a lot in my git days, I don't miss it at all while using jujutsu. The benefit of jj is the ease with which one makes branches (without needing to name them). That's why you may not have liked the advice in mercurial - it wasn't the solution that was problematic, but that mercurial didn't make it as easy as it should have been.
(Same goes for index - no one misses it once they switch to jujutsu).
TortoiseHG is a very good client that covers all common Mercurial operations and then some. It's on par with a couple of commercial git clients that I've used. On the server side, there's e.g. heptapod as a GitLab fork that has a deep Mercurial implementation.
It means that git invented a bunch of new jargon and ideas that confuses people exposed to it for the first time, where hg's usage metaphor hews closer to the received wisdom of people coming from stuff like subversion and perforce.
It's true that git's ad hoc command line UI isn't exactly it's greatest strength. But given the complexity of the design space here that's a pretty weak argument IMHO. The two weeks it takes to get the basic git workflow into your muscle memory pale in comparison to the years it'll take you to be good at bisection and tree maintainership.
It's also sort of a wrong argument in the modern world. People new to git have extensive assistive technologies available. There is, after all, no HgHub out there.
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.
Not quite true for mercurial. You also get stable identifiers for commits that remain the same even after being manipulated such as after rebases or amends. It also enables tracking the evolution of a changeset which then enables `hg evolve`.
Being content addressable isn’t a desirable feature in a user-friendly version control system. Who cares about it? Giving stable identifiers to commits is a much more needed feature.
> It’s trivial to separate that result into two or more steps
Okay first, tell me how to separate it into two or more steps. Second, tell me why a single operation in a user’s mental model need to be split.
That said, if/when stacked PRs become a first-class citizen in GitHub, more projects will see the benefit of this approach (though they'll probably mostly get there through squash-merges).
The plugins were usually shipped with mercurial so you didn't have to install them separately, but you needed to know that you had to enable them in a config. And I beleive this turned a lot of people off.
I think some of the extensions were very basic stuff like graph logging and colorized output -- and mq like you said. So it was kind of unfortunate that people got a bad impression of hg from that and bounced off.
For a complicated long running feature branch I can see it. Instead of repeatedly merging the root in during development it can be cleaner. Tools aren’t always good at figuring out in a PR what was written and what was caused by those merges from root. And history looks better at the end.
For a short branch that can merge cleanly or perhaps very close to it, I’d kind of rather have the ‘true’ history. I don’t think it’s worth it.
I’ve never understood the “everything must be rebased before every merge” desire.
Finally, in one team, I more or less forced a senior engineer use merge (or rather, I was in control of the project and did not force other developers to use rebase). After a year, he admitted that he no longer really saw a benefit in rebase and switched to just using merges in his own projects. He also noticed fewer merge conflicts this way.
"For a complicated long running feature branch" always simpler to repeatedly merge main into dev, easier conflicts solving etc
For simpler cases squash+rebase as default merge strategy trumps leaves a nice clean history.
Mercurial is a Distributed Version Control System created in 2005.
The project has been constantly active since then, fostering modern tooling, introducing new ideas, spawning multiple recent tools from its community, keeping itself competitive, and with sustained funding for its development. However nowadays, most people we encounter remember Mercurial for losing the popularity battle to its sibling Git in the 2010s and think the project dead.
This talk confronts this paradox. How did Mercurial get itself in such a situation? What can everyone learn from it? What does this mean for the future of version control?
Using our first hand knowledge of Mercurial's history, we look at a selection of events, contributor profiles, technical and community aspects, to see how they've affected the project's course.
We will focus on topics that we have been asked about most frequently, such as: * How has Mercurial weathered the Git storm? * Which impacts has Mercurial had on your life, unbeknownst to you? * How has the involvement from behemoth companies reshaped the project? * What brings people to Mercurial in 2025?
Finally, we leverage the knowledge extracted from our past, to assess the present state of version control, try to predict its future, and highlight how community-based open-source remains as relevant as ever.
Show a diff: svn diff / git diff
Show log with diffs: svn log --diff / git log --patch
Git calling the same or similar things different (or just terrible - tree-ish? ref?) names is one of the worst things about Git.
Mercurial's "branch" was generally intended for long-lived things. Think the "stable branch" or a "version X" support branch for a project.
The branch name is baked into the commits that use it. You can hide them from the UI with "--close-branch", but they will still exist forever in the commit history. This is both a good thing and a bad thing, depending on your desires.
This is different from Git's "branch" which is basically just a pointer to a commit. It is not part of commit history, it is just a convenience for the developer. Later, Mercurial added "bookmarks" which are similar.