Network Effects were a big part of it (lots of reasons why people are mentioning both GitHub and/or Linus' oversized impacts on picking a winner).

I think it is also worth pointing out: Mercurial also got bit by a lot of Anti-Python sentiment from very early on (laughingly, from some number of the same developers that didn't seem to mind how much git included a spaghetti mess of Perl and Bash scripts). The timing of the Python 2 -> 3 transition and the debacle that especially ensued as the various Linux distros made a particular dog's breakfast out of some of it also created additional or new Anti-Python sentiment among would be source control users.

I think Git was initially more popular and that had compounding effects that made it eclipse Mercurial.

In 2010 or so we tried to adopt Mercurial at the small company I worked at, but the support for Git was just so much better - even back then. Git's popularity meant that tooling, documentation, and general ease of finding people to ask questions was 100x easier with Git, so we switched. I'd imagine the same thing played out many times over.

A few FAANGs did and still use Mercurial, but they're on their own islands and don't really affect the wider tech ecosystem.

1. Github. 2. Git was created and used as a version control in the development of the Linux kernel. Some people may correctly think: if it's good enough to be the version control for Linux, it should handle my project.

GitHub made git popular, and git made GitHub popular.

So the major mercurial hosts (especially bucket) decided that it wasn't worth supporting even for their existing users. That was the mail in Mercurial's coffin. Google also decided to shut down their Google Code.

Git's appeal is that it is more flexible and has every feature you might want, allowing people to do whatever they wish whether it's pretty or not. As long as it works, people can look past the ergonomics. GUIs and AI shield most people from the UI.

Mercurial didn’t have the evangelical base that GitHub gave git. Mercurial was hard to see in the real world. Mercurial was not taken up by the young programmers. Soon enough fewer young programmers meant more expensive development time because older more experienced programmers would be maintaining the code.

But I think the biggest reason mercurial did not do well was because the viral network was not there.

If hg wants to still be relevant, it should copy all of git’s commands and features and then supplement it with native features.

Mozilla still uses Mercurial for Firefox development [0]. They're in the process of moving to git and GitHub [1]. I don't know the status of the move, but I contributed a bit to Firefox's build system via Mercurial, and I am glad to see they're moving to git since it's the industry standard. Mercurial felt so alien when I was using it. Git has its own share of UX problems, but finding support for Mercurial was much harder for me, precisely because nobody really uses it anymore.

References:

0: https://hg-edge.mozilla.org/

1: https://groups.google.com/a/mozilla.org/g/firefox-dev/c/Qnfy...

Facebook still uses Mercurial for their monorepo, as far as I know. I suspect GitHub is the reason git ultimately won. It became the easy default choice compared to the decision making involved with setting up local version control. For the record, last time I had to make that choice for my team pre-GitHub, I went with hg.

Github was part of it. The other part was Linus being the author of Git and putting his weight behind it. It wasn't for technical reasons.

Github - it was a free hosting for your code which served also as your backup, as back then there were not many VCS hosting services and certainly none, or very few, that were free. Github changed how we approach VCS and code on a world scale.

Network effects, powered by GitHub. Back in the day I loved Hg. Logical and rounded-edges where Git was geeky, tweaky, and rough. And the how many uses this vs. how many use that numbers were not so unequal. Tossup IIRC. But GitHub made Git easy to use as a team, collaborative and social, whereas Bitbucket made it easier but not with the same enthusiasm . Small advantages in user base size, branding, and ease of being supported "in the cloud" compounded over time, until suddenly using Mercurial seemed unusual and off the beaten path yet using Git felt natural and common. When supporting services (like CI/CD services) grew, it was clear who'd they support first. The market leader, natch. And so the momentum grew. Classic VHS vs Betamax.

1. Both tools are good enough. Source control is an engineering practice. Good enough is the core of engineering.

2. Source control was and is an expanding market. Beginners don't have the experience to make informed decisions about ergonomics and other nuances. More or less the features of git vs mercurial don't matter when a person adopts source control for the first time.

3. Ecosystems trump ergonomics...e.g. github. So does branding...i.e. the software Torvaldes wrote. And if I could make a bet, I'd bet Torvaldes writes software about as good as anyone on the Mercurial team, if not better.

We stopped because it was horribly slow on large repos. People confuse mercurial now with mercurial then. It has improved a lot.

Github made hosting git free with private repos

I used it as a replacement for Subversion for awhile. At some point, I wasn't able to find answers for tech issues I was having (bug workarounds, crashing) and was forced to move to git.

Have you actually used it?

Mercurial and “ergonomics” are not too words often uttered in the same sentence.

FWIW at Google I use it daily

Personally I went from subversion to git. never really made the mercurial stop.

For me, I keep branching super simple, but that was the big one for people. Git branching was far superior to mercurial.

Computing is a winner-take-all industry.