I kind of killed Mercurial at Mozilla

Original Article ↗ Hacker News Discussion ↗

Mozilla’s move from Mercurial to Git and GitHub is framed as part of a broader shift where Mercurial, despite a friendlier CLI and strong features, has been eclipsed by Git’s network effects, tooling ecosystem, and backing from giants like Microsoft, Meta, and Google. Commenters revisit why earlier Mercurial hosts such as Bitbucket abandoned it, how large companies now wrap custom systems (Sapling, jj, Perforce, Piper) around Git-like models, and why many developers still find Git’s UX confusing compared to Mercurial. The thread also weighs GitHub’s weak code review ergonomics and the lock‑in risks of Mozilla relying on a Microsoft‑owned platform against the practical benefits of aligning with the dominant infrastructure for open source collaboration.

Mercurial’s decline and network effects

  • Many see Mercurial as effectively “over”: Bitbucket dropped hg, major hosts are Git-only, new Mercurial adoption is tiny.
  • Others counter that Mercurial is still maintained, runs on Python 3, has Rust components, and gains features like Changeset Evolution.
  • Consensus: Git won largely through network effects (Linux kernel, GitHub, tooling ecosystem). Once people learn Git, switching feels low‑ROI even if hg is nicer.

Hosting platforms and the missing “HgHub”

  • Bitbucket is repeatedly cited as the de facto “hghub” that started hg-only, then added Git, then removed hg.
  • Some call the Mercurial removal shortsighted; others argue hg use had fallen below 1% of new users and supporting two VCS systems wasn’t worth it.
  • SourceHut and Heptapod are mentioned as remaining Mercurial-friendly hosts.

Big-company VCS stacks (Meta, Google, Microsoft)

  • Meta historically scaled Mercurial; now exposes Sapling, a Mercurial‑derived system with Git compatibility. Internally, people still use hg-style commands but the open-source Sapling has diverged and is more its own VCS.
  • Sapling’s Git interop is described as useful but still rough (LFS issues, force‑push friction, large repo edge cases).
  • Google fronted its monorepo (Piper) with a Mercurial-based client because hg had a real wire protocol; work is underway to replace this with jj (Jujutsu), which borrows UX ideas from hg while interoperating with Git storage.
  • Microsoft invested heavily to make Git scale for huge repos and partial clones.

Git vs Mercurial UX and philosophy

  • Many praise hg’s cleaner CLI, consistent terminology, good Windows GUIs (e.g., TortoiseHg), and features like revsets and phases.
  • Many also criticize Git’s confusing commands, dangerous flags, and idiosyncratic concepts (index/staging area, stash, reset --hard).
  • Counterpoint: much of the perceived difficulty is learning distributed VCS concepts, not Git specifically; once understood, Git is powerful and hard to truly lose data with (reflog, etc.).
  • Historical divergence: Git embraced history rewriting early; Mercurial was philosophically wary, leading to tools like MQ and later more complex models (phases, evolve).

Code review workflows and GitHub UI

  • Strong criticism of GitHub PR review for serious/stacked workflows: poor handling of multiple versions, lost context after rebases, weak range-diff support, limited commenting on unchanged lines, and awkward multi‑round reviews.
  • Systems like Gerrit and Phabricator are praised for per‑commit/stacked diffs and clear evolution across patch versions.
  • Third‑party tools (Graphite, CodeApprove, Reviewable) attempt to layer better review and stacked-diff workflows on top of GitHub.

Large repos, monorepos, and binaries

  • Git’s monorepo story is seen as historically weak (submodules, sparse checkout, partial clone arrived late). Some argue Git isn’t a good fit for Google‑style monorepos without heavy tooling.
  • Others maintain Git is fine for large repos below “Google scale” and that monorepos mostly expose process/organization issues.
  • Game and ASIC development are said to rely on Perforce for large binaries; Git LFS is widely supported but called clunky and workflow‑heavy compared to Mercurial’s largefile handling.

Alternatives and future directions

  • Several people like Fossil’s all‑in‑one approach (VCS + issue tracker + web UI) and single-binary deployment.
  • Pijul is mentioned as an advanced patch-based VCS that some hope will become more common.
  • Jujutsu is highlighted as a promising Git‑compatible VCS with an operation log and built‑in undo, aiming to modernize VCS UX beyond both Git and Mercurial.

Mozilla’s move to Git/GitHub

  • Many accept Mozilla’s switch to Git as pragmatic given ecosystem realities and internal reliance on Git tooling (e.g., git-cinnabar as a bridge).
  • Some argue choosing GitHub specifically conflicts with Mozilla’s stated values around decentralization and makes contribution dependent on a Microsoft‑controlled account.