By admin , 29 April 2026

The 2005 inflection

BitKeeper had been the Linux kernel's VCS until April 2005, when licence disputes ended that arrangement. Linus Torvalds wrote Git in 10 days. Matt Mackall began Mercurial weeks later, with similar goals and similar performance. The two systems competed for adoption from a level start.

The Linux factor

The Linux kernel is the largest, most influential open-source project in history. Its choice of Git meant kernel contributors used Git, its tooling integrated with Git, and adjacent communities followed. Many of the early Git contributors and committers were kernel hackers; their habits shaped Git's defaults.

The GitHub factor

GitHub launched in April 2008. Its success was not predicted by either Git's or Mercurial's technical merits - it was about social features (forks, pull requests, issues) layered on Git. By 2010 GitHub was the OSS hub; by 2015 it was synonymous with software development for many engineers.

Bitbucket initially supported only Mercurial; GitHub supported only Git. By the time Bitbucket added Git in 2011, GitHub had built insurmountable momentum. Bitbucket eventually deprecated Mercurial in 2020.

Network effects

The cost of switching VCS scales with team size and ecosystem investment. Once GitHub became the de facto OSS host, every project hosted there was a Git project; every developer learning Git through OSS became a Git advocate at work. The compounding favoured Git regardless of merit.

Where Mercurial advocates remain

  • Mozilla (Firefox, Thunderbird) used Mercurial for over a decade; migrated to Git in 2023.
  • Meta (Facebook) extensively used Mercurial; built Sapling as a Mercurial-influenced replacement.
  • Some scientific projects use Mercurial for cultural reasons (Python-flavoured tooling).

What Git did right

  • Speed - C core was fast from the start; performance was a deliberate priority.
  • Flexibility - exposed plumbing meant tooling could be built on top quickly.
  • The Linux kernel as a public proof point - any project could see Git scaling to the largest OSS effort in the world.
  • Fast iteration - the project absorbed user feedback aggressively in early years.

What Mercurial did right

  • UX - clean CLI, helpful errors, gentle defaults.
  • Extension model - clean Python API, gated dangerous operations.
  • Documentation - tutorial-shaped, accessible to newcomers.
  • Conservative defaults - dramatically fewer "I lost my work" stories per user.

The lessons for tool design

  • Technical merit alone does not decide adoption.
  • Ecosystem and host integration matter more than CLI elegance.
  • An advocate at the centre of an influential community (Linus + kernel) outweighs years of polish elsewhere.
  • UX improvements lag market dominance; once Git won, it could afford to fix its rough edges.

Migration paths today

# Mercurial to Git
git clone https://github.com/frej/fast-export.git
cd source-hg-repo
git init ../target-git-repo
cd ../target-git-repo
~/fast-export/hg-fast-export.sh -r ../source-hg-repo

# Cross-mirror via hg-git
hg clone https://example.com/repo
cd repo
hg push git+ssh://github.com/user/repo.git

The respectful conclusion

Mercurial is not extinct - it powers important infrastructure and continues to receive updates. Its design lessons influenced Git's evolution. For new projects, the right answer in 2026 is almost always Git, but the choice should be made knowing why, not by reflex. Mercurial users have nothing to apologise for; the system did its job and inspired a generation of tooling.