Same era, different aesthetic

Git and Mercurial were both released in April 2005, both as responses to BitKeeper's licensing fallout. Linus Torvalds wrote Git for the Linux kernel; Matt Mackall wrote Mercurial as a competing alternative. Both are content-addressed, distributed, DAG-history systems - and both work.

Git's stance: power, edges, and trust the user

Git exposes its internals. The plumbing commands (cat-file, update-ref, hash-object) are documented and recommended for scripting. Rewriting history is encouraged. Branches are pointers, mutable and cheap. The user is presumed competent and given sharp tools.

Mercurial's stance: safety, consistency, and conservatism

Mercurial hides internals more aggressively. Default commands rarely rewrite history; doing so requires explicit extensions (mq, histedit, strip). Branches are permanent metadata on commits, not mutable refs. The user is presumed mortal and shielded from sharp edges.

The branch model

# Mercurial: named branches are permanent
hg branch feature/login
hg commit -m "Start work"
# The branch name is now baked into the commit's metadata.

# Mercurial: bookmarks are like Git branches (mutable pointers)
hg bookmark feature/login
hg commit -m "Start work"
hg bookmark -m feature/login feature-rename

# Git: branches are mutable pointers
git checkout -b feature/login
git commit -m "Start work"
git branch -m feature-rename

Mercurial's named branches make history forensics easier (the branch is in every commit), but make renaming and deletion ugly. Git's mutable refs make experimentation cheap.

The CLI experience

Mercurial's CLI is more uniform - commands and options follow consistent conventions. Git's CLI grew over decades and has rough edges (checkout doing four different jobs is the canonical example, partially fixed by switch and restore). Newcomers report Mercurial as more pleasant; veterans of Git stop noticing the warts.

Speed

Both systems are fast on typical projects. Git tends to be faster on very large repos thanks to relentless optimisation; Mercurial's pure-Python history was historically slower, though Rust extensions (rust-cpython) have closed the gap. For 99% of users, either is "instant".

Extensions and scope

Mercurial's extension model is first-class - bundled extensions (histedit, mq, shelve, rebase) gate themselves behind opt-in enables, signalling "this changes assumptions". Git ships everything in one binary; the user picks subcommands. Mercurial's gate is gentler; Git's exposure is more honest.

The history rewriting question

Both can rewrite history. Mercurial defaults to refusing - you must enable histedit or rebase. Git defaults to allowing - git rebase -i is built in. The Mercurial team's view: rewriting published history is rare and dangerous; require an explicit choice. Git's view: rewriting is a useful tool; the user can decide.

Hash function

Both use SHA-1 historically. Git is migrating to SHA-256 (transition ongoing); Mercurial maintains SHA-1 with planned options. Both are robust enough in practice; collisions remain theoretical at scale.

Real-world divergence

Facebook (now Meta), one of the largest Mercurial users, forked it for monorepo scale, building tools (Sapling) that diverged significantly. Mozilla used Mercurial for Firefox until migrating to Git in 2023. Google internally uses neither directly, having built bespoke systems on borrowed ideas.

Why ecosystem matters more than technical purity

The Mercurial CLI is arguably more learnable. The defaults are arguably safer. Yet Git won market share because GitHub bet on Git, the Linux kernel kept choosing Git, and tooling vendors followed. By 2015 the ecosystem gap was insurmountable; by 2020 most Mercurial holdouts had migrated.

What to take from Mercurial

Even on a Git project, Mercurial's lessons apply: prefer safe defaults, gate dangerous operations behind explicit opt-in, treat published history with care. Mercurial's spirit lives on in Git tooling that pursues those values.