The Ten-Day Rebellion: How Linus Torvalds Built Git After Losing Access to BitKeeper

The Ten-Day Rebellion: How Linus Torvalds Built the Tool Running Your Code

Every time a developer types git commit, git push, or curses at a merge conflict, they're using software that exists because of a corporate licensing dispute that lasted less than two weeks to resolve — not through lawyers, but through code. Git, the version control system that now underpins nearly all modern software development, wasn't the product of a startup or a committee. It was written by one famously blunt Finnish-American engineer, Linus Torvalds, in about ten days, because he refused to keep begging a company for permission to maintain his own project.

The Tool Linux Depended On

By 2005, the Linux kernel — the operating system core that already powered everything from servers to embedded devices — had grown too large and too collaborative for Torvalds and his team of maintainers to track changes by email and patches alone. Since 2002, the kernel team had relied on BitKeeper, a proprietary distributed version control system made by a company called BitMover. BitMover's founder, Larry McVoy, had granted the Linux community a free license as a goodwill gesture, letting thousands of contributors use a commercial-grade tool without paying for it.

That arrangement collapsed in April 2005. Andrew Tridgell, the Australian engineer best known for creating Samba (the software that lets Linux machines talk to Windows networks), had been experimenting with reverse-engineering parts of BitKeeper's network protocol — reportedly just to understand how it worked, not to build a competing product. BitMover saw it differently, and revoked the free license for the entire Linux kernel community in response.

Torvalds was left without the tool his project depended on, and with no appetite for going back to a patchwork of emailed patches for a kernel with thousands of contributors scattered across the world.

Ten Days, One Engineer, No Shortcuts

Rather than adopt another existing system, Torvalds decided to write his own from scratch. According to the Linux Foundation's own project history and contemporaneous accounts, he began work on April 3, 2005. By April 6 he announced the project to the kernel mailing list, and by April 7 the tool was already being used to manage its own source code — a milestone known in version control circles as "self-hosting." The first real multi-branch merge followed on April 18.

Torvalds' design goals were blunt and specific, shaped directly by what had just gone wrong: the system had to be fully distributed, so no single company or server could ever again hold the project's history hostage. It had to be fast, even on a codebase with hundreds of thousands of files and years of history. And it had to handle branching and merging — developers working on separate copies of the code and combining their changes later — as a normal, cheap operation rather than a rare, risky one. Those priorities are still the reason Git works the way it does today.

By mid-June 2005, barely two months after that first commit, Git was mature enough to manage the release of Linux kernel version 2.6.12. Torvalds, never interested in long-term maintenance work, handed the project over to developer Junio Hamano in July 1 2005. Hamano has served as Git's lead maintainer ever since — a 20-year run on a project its creator originally expected to hand off within weeks.

A Name That Was Also an Insult

The name itself is one of software history's better-known self-deprecating jokes. "Git" is British slang for an unpleasant or contemptible person, and Torvalds has said plainly that he names his projects after himself: first Linux, then Git. The man page for the tool still describes it, only half-jokingly, as "the stupid content tracker." The backronym some people cite — "Global Information Tracker" — was invented afterward, as a more presentable cover story for a name that started as a joke about its own creator.

From Kernel Utility to Global Infrastructure

Git's rise from a kernel-maintenance tool to the default language of software collaboration took a vehicle it wasn't originally built to need: a hosting platform. GitHub launched in April 2008, built by Tom Preston-Werner, Chris Wanstrath, P.J. Hyett, and Scott Chacon, and it did for Git what a good interface does for any powerful but unglamorous tool — it made collaborating on code social, visual, and easy to show off. Competing platforms like GitLab and Bitbucket followed, but GitHub's dominance was large enough that Microsoft paid $7.5 billion to acquire it in 2018, folding a tool literally built in protest against corporate lock-in into one of the world's largest software companies.

The scale today is hard to overstate. GitHub's own 2025 State of the Octoverse report puts the platform at more than 180 million developers worldwide, with over 36 million joining in the twelve months to August 2025 alone and commit activity up roughly 25% year over year — growth driven in large part by developers outside the United States, with India overtaking the US in total contributor count for the first time. Underneath nearly all of that activity is still the same distributed version control engine Torvalds wrote in a ten-day sprint two decades ago.

Why This Still Matters

For teams building software anywhere, including the fast-growing developer communities across the Gulf, Git's design choices aren't abstract history — they're why a team in Dubai can collaborate with contractors in another time zone without anyone needing to be online at the same time, why a mistake can be rolled back instead of becoming permanent, and why open-source collaboration at a global scale is even possible. It's a reminder that some of the internet's most load-bearing infrastructure wasn't built by a committee planning for the future, but by one engineer who got locked out of his tools and decided, over about ten days, to make sure that could never happen to his project again. ARTICLE_EOF