The Roads Not Taken

The Same Day, A Different Choice

On April third, two thousand five, Linus Torvalds sat down in Portland and started building Git. We told that story in episode four. But here is something most people do not know. Within weeks of that Sunday, at least four other developers looked at the same wreckage of the BitKeeper crisis and said: I can solve this too. The same problem. The same moment. Radically different designs.

The most striking parallel was a developer named Matt Mackall. While Linus was writing C as fast as he could type, Mackall was writing Python. While Linus optimized for raw speed above everything else, Mackall optimized for something different: simplicity. While Linus named his tool after himself, a self-deprecating British insult, Mackall named his after the element mercury, the metal that flows and changes shape. Mercurial.

By April twentieth, two thousand five, just seventeen days after Linus started Git, Mackall had posted his first message to the Linux Kernel Mailing List describing Mercurial's design. By April twenty-fifth, he was posting benchmark comparisons against Git. Two tools, born from the same crisis, racing to solve the same problem, already competing for the same community's attention.

Twenty years later, Git won so completely that most developers have never heard of Mercurial. Or Darcs, the mathematician's version control system built on an algebra of patches. Or Bazaar, which Canonical bet Ubuntu's entire development workflow on. Or Fossil, the deliberately isolated tool that Richard Hipp built for SQLite and still uses today.

These are the roads not taken. And the story of why Git won is not the story you think it is.

Matt Mackall and the Python Path

Matt Mackall was not some newcomer trying to cash in on the BitKeeper crisis. He was a kernel developer. He had contributed to Linux memory management, written the netpoll subsystem used for kernel crash dumps over the network, and maintained the random number generator. He understood the kernel's workflow from the inside.

When BitMover revoked the free licenses and the kernel mailing list erupted with two hundred and five emails arguing about what to do next, Mackall had a specific diagnosis. The existing alternatives were not just slow. They were poorly designed. Monotone was architecturally interesting but glacially slow. GNU Arch had a notoriously hostile interface. Subversion was centralized. And Git, which Linus was building at frightening speed, was raw and dangerous, a collection of low-level plumbing commands with no porcelain on top.

Mackall's bet was that Python could give him something Linus's C could not: a tool that was approachable from day one. Not just fast for experts, but usable for everyone.

Despite the above, it compares pretty well to Git in speed and is quite a bit better in terms of storage space.

And he was right, at least initially. His benchmark comparisons from April two thousand five showed Mercurial checking in the first twelve Linux two-point-six releases in twenty-five seconds. Git took eighty-eight seconds for the same operation. Mercurial's storage was larger for the initial import but more efficient for incremental changes, thanks to a delta compression scheme that Mackall had designed specifically for network efficiency. His argument was prescient: most developers would use version control over a network, and the common case for Git would find most of its speed wasted on waiting for the network.

The architectural differences ran deep. Git stored snapshots. Mercurial stored deltas. Git used a content-addressable object store where every piece of data got a unique fingerprint. Mercurial invented something called a revlog, a structure that combined delta compression with fast random access, storing changes efficiently while still allowing quick jumps to any point in history. Both used SHA one hashes, but Mercurial also gave every changeset a simple local integer number, zero, one, two, three, so you could say "show me revision four hundred and twelve" instead of pasting a forty-character hexadecimal string.

The user experience gap was enormous. Where Git exposed its internal plumbing and expected users to learn the difference between the index, the working tree, and the repository, Mercurial presented a clean, consistent interface. Commands did what their names suggested. Help text was readable. Error messages were helpful. The learning curve was gentle enough that teams could adopt Mercurial without a week of training.

And Mercurial had one more thing going for it: it was written in a thousand lines of Python. Readable, hackable, extensible Python. Anyone could open the source, understand what was happening, and write an extension. Git's C codebase was fast but impenetrable to casual contributors. Mercurial's Python codebase was an invitation.

For several years, the outcome was genuinely uncertain. Mercurial won serious adoption. Sun Microsystems chose it for OpenSolaris and OpenJDK. Mozilla chose it in two thousand seven for Firefox development, partly because Git's Windows support at the time was abysmal. Facebook, running one of the largest monorepos in the world, chose Mercurial over Git and invested heavily in making it scale.

The Python community adopted Mercurial. The Google Code hosting service supported Mercurial alongside Subversion. Major companies evaluated both tools side by side and often chose the one that was easier to learn.

So what went wrong?

The Mathematician's Version Control

Before we answer that question, let us take a detour into something beautiful and impractical. Because while Linus and Mackall were racing to build tools that worked, a physicist named David Roundy was building something that was correct.

Roundy was a physics researcher, and he approached version control the way a mathematician approaches any problem: from first principles. What if, instead of tracking snapshots of files or storing deltas between versions, you thought about changes themselves as the fundamental objects? Not what the code looks like at a given moment, but what transformations were applied to get there.

This is patch theory. And the tool Roundy built on top of it was called Darcs, short for David's Advanced Revision Control System. He started it in two thousand two, writing the initial version in C++ before rewriting it in Haskell, because of course you write your mathematically rigorous version control system in Haskell.

The core insight was this. In Git, if you have two branches with different changes, those changes are bound to the specific commits that created them. The order matters. Commit A followed by commit B gives you a different history than commit B followed by commit A, even if the end result is the same. In Darcs, patches are more like mathematical operations. If two patches touch different parts of the code, they commute. You can apply them in either order and get the same result. Darcs understands this automatically.

Intuitively, a patch B depends on another patch A if A provides the content that B modifies. Patches that modify different parts of the code are, by default, independent.

That was the core insight: version control should track changes like mathematical operations. If two patches touched different parts of the code, they could be applied in any order. No conflicts. No guesswork. Just math.

Think about what this means for cherry-picking, one of the most common and most error-prone operations in Git. In Git, cherry-picking a commit from one branch to another creates a new commit with the same changes but different metadata. It is a copy, and it can cause problems if you later merge the branches, because Git sees the original and the copy as different things. In Darcs, cherry-picking is just reordering patches. The patch is the same patch regardless of where it lives. There is no copy, no duplicate, no confusion.

Darcs made merge conflicts conceptually impossible in cases where patches were truly independent. It could automatically determine which patches could be reordered and which could not. The merge operation was not a heuristic guess, like Git's three-way merge. It was a mathematical calculation.

The problem was performance. Darcs had what the community called the exponential merge problem. In certain cases, particularly repositories with long, interleaved histories of changes to the same files, the patch commutation calculations could explode in complexity. Operations that should take seconds would take minutes. Operations that should take minutes would take hours. In extreme cases, they would never finish at all. The tool would sit there, churning through combinatorial possibilities, consuming memory until the machine ran out.

For small projects, Darcs was a revelation. The GHC Haskell compiler used it for years. The Haskell community loved it, naturally, since it was written in Haskell. It attracted a devoted following of developers who appreciated its mathematical elegance. But for anything approaching the scale of the Linux kernel, or even a moderately large commercial project with many parallel branches, Darcs was unusable.

Roundy had built the version control system equivalent of a Formula One engine that could not handle traffic. Beautiful engineering. Impractical transportation.

Canonical's Bet

In February two thousand five, a month before the BitKeeper crisis, a developer named Martin Pool received an interesting job offer. Canonical, the company behind Ubuntu Linux, was hiring him to lead development of a new version control system. Mark Shuttleworth, Canonical's founder and a man who had literally been to space, wanted his company to own its development tools. The project was called Bazaar.

This was not Canonical's first attempt at version control. An earlier tool called Bazaar, confusingly sharing the name, had been developed by the same community. The new project, sometimes called Bazaar-NG or simply bzr, was a ground-up rewrite. Pool, who had been reviewing and cataloguing version control systems on his blog for years, had strong opinions about what a modern tool should look like.

Bazaar's pitch was flexibility. Where Git was opinionated about distributed workflows and Subversion was opinionated about centralized ones, Bazaar tried to support both. You could use it as a centralized system with a single server, like Subversion. You could use it as a fully distributed system with local branches, like Git. You could mix and match. The idea was to meet teams where they were and let them migrate gradually from centralized to distributed as they grew comfortable.

It was also written in Python, like Mercurial, and shared some of the same accessibility advantages. Commands were consistent. Documentation was thorough. The learning curve was manageable.

And Bazaar had something none of the others did: corporate sponsorship from a company that would actually use it. Canonical mandated Bazaar for all of Ubuntu's development. Launchpad, Canonical's hosting platform, was built around Bazaar. The tool had a guaranteed user base of thousands of Ubuntu contributors. GNU Emacs adopted it. MySQL used it for a time.

For about five years, Bazaar looked like a serious contender. Canonical had a full-time team working on it. The tool improved steadily. The community grew.

Then, slowly, the air went out. The fundamental problem was speed. Bazaar was not fast enough. Operations that took milliseconds in Git took seconds in Bazaar. On large repositories, the gap widened to minutes. Developers who tried Bazaar after using Git found the performance difference viscerally painful.

In early two thousand twelve, Canonical reassigned the Bazaar team to other projects. The official line was that they would still fix occasional bugs. In practice, the project was being abandoned. Martin Pool left Canonical in April two thousand twelve, and the pace of development slowed to a crawl.

The dominoes fell quickly after that. In two thousand thirteen, the GNU Emacs mailing list erupted with a discussion about whether Bazaar was still effectively maintained. Eric Raymond, never one to mince words, coordinated a migration from Bazaar to Git that completed in November two thousand fourteen. Other projects followed. By two thousand fifteen, Bazaar was effectively dead, maintained only by a handful of volunteers who cared more about the existing repositories than the tool's future.

And in June two thousand twenty-five, Canonical finally made it official. Bazaar support on Launchpad would be discontinued by December. Projects had to migrate to Git. The company that had created the tool, mandated it for its own development, and built an entire hosting platform around it, was pulling the plug. Twenty years after Martin Pool joined Canonical to lead the project, the last lights were going out.

Richard Hipp's Deliberate Island

But not every alternative to Git was trying to win. Some were trying to escape the game entirely.

D. Richard Hipp is best known for creating SQLite, the most widely deployed database engine in the world. It runs on every smartphone. It is embedded in every web browser. It sits inside aircraft avionics, automotive infotainment systems, and medical devices. SQLite is everywhere, and Hipp has spent decades making it bulletproof, achieving one hundred percent modified condition and decision coverage in his test suite, a standard borrowed from aviation safety certification.

In two thousand six, Hipp started building Fossil. Not because Git did not exist. Not because Mercurial was inadequate. Because he wanted something different.

When you control your own tools, you can go further and do things that you cannot do if you are depending on somebody else for your tools.

Fossil is not just a version control system. It is an integrated project management tool. A single Fossil repository contains version control, bug tracking, a wiki, a blog, a forum, a web interface, and a timeline of all activity. Everything lives in one file. One SQLite database file. You can email a Fossil repository to a colleague as an attachment. You can back it up by copying a single file. You can browse the entire project history, including tickets and wiki pages, by running one command that starts a local web server.

This is the polar opposite of Git's philosophy. Git is a small, sharp tool that does one thing: track content. If you want bug tracking, install Jira. If you want a wiki, use Confluence. If you want continuous integration, set up GitHub Actions. Each piece is separate, maintained by different teams, connected by configuration.

Fossil bundles everything together, deliberately. And Hipp considers this a feature, not a limitation.

Git is absolutely the best version control system in the world for Linux kernel development. Fossil optimizes for small teams where everybody knows each other, everybody sees everybody else's work all the time.

There are deeper philosophical differences. Git's default workflow encourages private work. You branch, you commit locally, you push when you are ready. Fossil's default workflow encourages transparency. Every commit is automatically synced to the server. Every team member sees every change as it happens. Hipp designed this intentionally. On a small team, he argues, visibility prevents problems. You do not need code review gates when everyone can see what everyone else is doing in real time.

With Git, when you make changes, you push them up to somebody else. With Fossil, the default configuration is every time you commit a change, it automatically pushes your changes up.

Hipp also considers Git's rebase command harmful. Rebase rewrites history, discarding the record of what actually happened in favor of a cleaner narrative. For a man whose database product is used in aircraft that carry human beings, the idea of deliberately destroying records is not just distasteful. It is dangerous.

And here is the thing about Fossil that makes it unique among Git's alternatives: Hipp does not want Fossil to win. He has no interest in network effects, in market share, in being the standard. SQLite has used Fossil since two thousand six, and it will continue to use Fossil regardless of what the rest of the world does. The SQLite project has over twenty years of history in Fossil, every bug report, every wiki edit, every commit, all in a single database file that Hipp controls completely. He is not on a road that diverges from Git. He is on a different road entirely, going to a different destination.

When someone suggested that SQLite should mirror its repository on GitHub to make contributing easier, Hipp's response was characteristically direct. He set up a GitHub mirror, read-only, but left a note making clear that the authoritative repository remained on Fossil. Contributions would come through Fossil's own processes, not through pull requests.

Fossil will never replace Git. Hipp knows that. He does not care. He built a tool that perfectly serves his project, and he will use it for as long as SQLite exists. In a world obsessed with network effects and winner-take-all dynamics, that kind of deliberate self-sufficiency is almost radical.

The Modern Challengers

After two thousand ten, the question was no longer whether Git would dominate. It was whether anything could challenge that dominance.

Pijul entered the conversation around two thousand sixteen, built by Pierre-Etienne Meunier and other developers who were frustrated by the same problems that had haunted Darcs. Pijul took patch theory seriously but tried to solve the exponential merge problem that had killed Darcs. Where Darcs used a theory that could explode in complexity, Pijul was built on a cleaner mathematical foundation that promised correct merges without the performance collapse.

The technical arguments for Pijul are genuine. Merge conflicts in Git are fundamentally heuristic. Git guesses at the right merge based on a three-way comparison. Most of the time it guesses right. But when it guesses wrong, the developer has to manually untangle the mess. Pijul's patch theory makes certain classes of merge conflict impossible by construction, not by guessing but by mathematical proof.

But Pijul arrived a decade too late. By two thousand sixteen, Git had GitHub. Git had Stack Overflow answers for every conceivable problem. Git had tutorials, books, courses, bootcamps, and enterprise tooling. Git had become the answer to "what version control should we use?" not because every team evaluated alternatives, but because nobody evaluated alternatives anymore. The question had stopped being asked.

Jujutsu is even newer, started around two thousand twenty-two by a Google engineer named Martin von Zweigbergk. It is not a replacement for Git. It is a different interface to Git's storage. Jujutsu keeps Git's content-addressable backend but replaces the command-line interface with something inspired by Mercurial's simplicity and Pijul's patch-oriented thinking. Every working-copy change is automatically recorded. There is no staging area. Conflicts are first-class objects that can be committed and resolved later.

When Mozilla began migrating Firefox from Mercurial to Git in two thousand twenty-three, several Mozilla developers discovered Jujutsu and adopted it as their Git frontend. For developers who had spent years with Mercurial's clean interface, Jujutsu offered a way to work with Git repositories without suffering through Git's notoriously confusing commands.

But Jujutsu, like Pijul, faces the same wall. The network effects are not in the storage format or the command-line interface. They are in the ecosystem. In the CI pipelines. In the hosting platforms. In the millions of Stack Overflow answers that start with "git checkout" and not "jj new."

Why Git Won (And Whether It Deserved To)

Let us be honest about what happened.

Git did not win because it was easier to learn. Mercurial was easier to learn. Every usability study, every new developer survey, every anecdotal comparison pointed the same direction. Mercurial's commands were more intuitive, its error messages were more helpful, its documentation was more accessible. Git's interface was, and remains, notoriously confusing. The staging area bewilders beginners. The difference between reset, revert, and checkout baffles experienced developers. The man pages read like they were written for compiler authors, because they were.

Git did not win because it was the only distributed system. Mercurial was distributed. Bazaar was distributed. Darcs was distributed. All of them appeared within months of each other, responding to the same moment in history.

Git did not win because its design was objectively superior. Mercurial's revlog storage was arguably more space-efficient for common operations. Darcs' patch theory was more mathematically sound for merging. Fossil's integrated approach solved real workflow problems that Git's ecosystem required five separate tools to address.

Git won because of GitHub.

That is the uncomfortable truth that the Git origin story usually glosses over. Git was faster than Mercurial at the specific operations Linus cared about: applying patches, computing diffs on huge codebases, handling the Linux kernel's unique workflow of thousands of parallel branches merging through a hierarchy of maintainers. For kernel development, Git was unambiguously the right tool.

But most developers are not working on the Linux kernel. Most developers are working on web applications, mobile apps, libraries, and services with teams of three to thirty people. For those teams, Mercurial would have worked just as well. Bazaar would have worked just as well. The technical differences between Git and Mercurial were real but marginal for typical use cases.

What was not marginal was GitHub. When Tom Preston-Werner, Chris Wanstrath, and PJ Hyett launched GitHub in two thousand eight, as we heard in episode ten when Tom sketched the fork button on a napkin, they built it exclusively for Git. Not for Mercurial. Not for Bazaar. Not for any version control system. Just Git. And they added something none of the version control tools had: a social layer. Profiles. Followers. Stars. The fork button.

Bitbucket launched in two thousand eight with Mercurial support, and later added Git. Google Code supported both Mercurial and Subversion. Launchpad supported Bazaar. But GitHub's focus on Git, combined with its social features and its free hosting for open source, created a gravitational pull that the other tools could not escape.

Open source projects moved to GitHub because that was where the contributors were. Contributors were on GitHub because that was where the projects were. Each new project that chose GitHub made the next project more likely to choose GitHub. And choosing GitHub meant choosing Git.

By two thousand twelve, the network effect was self-reinforcing. By two thousand fifteen, it was insurmountable. Bitbucket dropped Mercurial support in two thousand twenty. Google Code shut down in two thousand sixteen. Launchpad is dropping Bazaar in two thousand twenty-five. The alternatives did not die because they were bad. They died because they were not Git, and Git was what GitHub used.

Mozilla's migration tells the whole story. When Mozilla chose Mercurial for Firefox in two thousand seven, it was a reasonable technical decision. Git's Windows support was poor. Mercurial was mature and well-suited to Mozilla's needs. For sixteen years, Firefox development ran on Mercurial. Hundreds of thousands of changesets. Hundreds of thousands of files. A massive, living codebase.

But by two thousand twenty-three, the pressure was unbearable. New contributors expected Git. Tooling assumed Git. Over a third of Firefox developers had already quietly started using a bridge tool called git-cinnabar to interact with the Mercurial repository through Git commands, because they did not want to learn a second version control system for one project. Mozilla hosted thousands of repositories on GitHub already. Firefox was the exception, not the norm.

In April two thousand twenty-five, Firefox's source of truth officially moved from Mercurial to Git. Sixteen years of Mercurial development, over. Not because Mercurial failed technically. Because the world had moved, and Mozilla could not afford to stand still.

Facebook's story is different but equally telling. Facebook chose Mercurial for its massive monorepo and invested enormous engineering resources into making it scale. They built a custom server called Mononoke, a virtual filesystem, and eventually an entirely new Mercurial-compatible client called Sapling. But even Facebook's investment could not sustain the ecosystem. The external Mercurial community shrank as developers migrated to Git. The tools, extensions, and integrations that third parties built for Mercurial dried up. Facebook was left maintaining an increasingly isolated fork of a tool the rest of the world had abandoned. In two thousand twenty-two, they open-sourced Sapling, but by then it was less a Mercurial successor and more a curiosity.

This is what network effects do to technology markets. It does not matter if your tool is better. It does not matter if your design is cleaner, your interface is friendlier, your theory is more rigorous. Once a critical mass of users commits to a platform, the switching costs become prohibitive. The ecosystem builds around the winner. The documentation accumulates around the winner. The hiring pipeline assumes the winner. And the alternatives, no matter how technically excellent, slowly starve.

VHS over Betamax. Windows over OS slash two. QWERTY over Dvorak. Git over everything else. The pattern is old and well-documented. Technical superiority is one factor among many, and it is rarely the decisive one.

So did Git deserve to win? That depends on what you mean by "deserve." Git is an extraordinary piece of engineering. Linus designed something in two weeks that has scaled to power the entire software industry for twenty years. The content-addressable store, the cheap branching, the distributed architecture, these are genuinely brilliant design decisions. Git is fast, reliable, and almost infinitely flexible.

But it is also confusing, hostile to beginners, and deeply weird in ways that have nothing to do with version control and everything to do with the fact that it was designed by one person for one very specific workflow in two very compressed weeks. The staging area exists because Linus needed it for kernel patch management. The reflog exists because the interface makes destructive mistakes too easy. The porcelain and plumbing distinction exists because the original interface was never designed for human beings.

Mercurial showed that distributed version control could be friendly. Darcs showed that merge conflicts could be solved mathematically. Fossil showed that version control could be part of something larger. Pijul showed that patch theory could work at scale. Jujutsu is showing that Git's storage can be wrapped in a better interface.

Git absorbed some of these lessons. It got easier over the years, partly by learning from Mercurial. The git switch command, added in two thousand nineteen, exists because git checkout was confusing. Git's documentation improved. Git's defaults became safer. But the core interface remains what Linus built in two thousand five, and twenty years of backward compatibility mean the rough edges will never be fully smoothed.

The roads not taken were not dead ends. They were real alternatives with real strengths that might have led to a different, and in some ways better, world. Mercurial might have given us a version control landscape where beginners were not terrified. Darcs might have given us a world where merge conflicts were a solved problem. Fossil might have given us integrated project management twenty years before we started gluing together six different cloud services to get the same thing.

But Git had GitHub. And GitHub had everyone. And once everyone was there, the roads not taken became roads not remembered.

There is one exception. In a workshop somewhere, Richard Hipp is committing changes to SQLite using Fossil. The commit syncs automatically to his server. The bug tracker updates. The wiki reflects the change. Everything lives in one file, one database, owned by one person who will never depend on anyone else's platform.

He is on a different road entirely. And he is doing just fine.

Git config is the least glamorous command in the toolbox and possibly the most important. Three layers: system, global, local. Each one overrides the last. Your name, your email, your default branch, your preferred editor, all live here. It is the foundation that every other command stands on, and most developers set it once and never think about it again, which is exactly how it should work.