Git: The Tool Linus Torvalds Built in Two Weeks Out of Spite

In April 2005, Linus Torvalds—the creator of Linux—found himself without a version control system. The tool he'd been using, BitKeeper, had revoked his license after years of tension between open source philosophy and proprietary software. His response? Build a replacement in two weeks. That replacement now manages the code for nearly every software project on Earth.

The Problem Before Git

For the first decade of Linux development, Linus managed code through patches and tar files. Developers would email patches—text files describing changes—and Linus would manually apply them. This was tedious, error-prone, and didn't scale. By 2002, Linux had thousands of contributors submitting patches daily.

The alternatives were underwhelming. CVS was the industry standard but painfully slow and prone to corruption. Subversion was newer but still centralized—every operation required talking to a server. For a project as distributed and fast-moving as Linux, none of these worked.

Then BitKeeper appeared.

The BitKeeper Years

BitKeeper was a proprietary version control system made by a company called BitMover. Its creator, Larry McVoy, was a former Linux developer who understood what Linus needed: a distributed system where every developer had a full copy of the repository. No central server required. Fast branching. Fast merging.

McVoy offered Linux developers free licenses to BitKeeper, despite it being commercial software. This was controversial. Many in the open source community believed the Linux kernel should only be built with free software. Using a proprietary tool felt like a betrayal.

Linus didn't care. BitKeeper was the best tool for the job. Ideology could wait.

For three years, it worked. Linux development accelerated. The kernel grew faster than ever. But tension simmered beneath the surface.

The Breaking Point

Andrew Tridgell was a respected developer, known for creating Samba (which lets Linux talk to Windows networks). He was also a reverse engineer by nature—he liked understanding how things worked.

Tridgell wanted to build a free client that could interoperate with BitKeeper. He reverse-engineered the protocol by connecting to a BitKeeper server and analyzing the traffic. This was legal but violated BitKeeper's license, which explicitly prohibited reverse engineering.

Larry McVoy was furious. He'd given away his software for free, and now someone was undermining his business model. He revoked the free license for all Linux kernel developers. Overnight, the entire Linux development workflow was thrown into chaos.

Two Weeks to Change the World

Linus evaluated alternatives: Monotone, GNU Arch, Darcs. None met his requirements. They were too slow, too complex, or too philosophical. He needed something specific:

• Speed: Patching should take seconds, not minutes
• Distribution: No central server, full history everywhere
• Integrity: Cryptographic guarantees that history can't be tampered with
• Simplicity: Simple internal model, even if the interface is complex

On April 3, 2005, Linus started writing. On April 7, Git was self-hosting—managing its own source code. On April 16, the first Git-managed Linux kernel patch was merged. Two weeks from nothing to production.

When asked how he accomplished this, Linus was characteristically blunt: "I'm an egotistical bastard, and I name all my projects after myself. First Linux, now Git."

(Git is British slang for an unpleasant person.)

The Design Decisions That Mattered

Git's design reflected Linus's specific needs and prejudices:

Everything is a snapshot, not a diff. Other version control systems stored changes between versions. Git stores complete snapshots, compressed and deduplicated. This seems wasteful but enables Git's incredible speed—to compare versions, you just compare snapshots.

Content-addressable storage. Every file, every commit, every tree is identified by a SHA-1 hash of its contents. This means identical content always has the same identifier. It also means history is immutable and cryptographically verifiable. Nobody can secretly change the past.

Branches are cheap. In Git, a branch is just a 41-byte file containing a commit hash. Creating a branch takes milliseconds. This encouraged a workflow of constant branching and merging, which was radical at the time.

The staging area. Git introduced the concept of an "index" or "staging area"—a place to prepare your commit before making it. This was confusing to newcomers but powerful for experts. You could commit parts of files, review exactly what you were committing, and craft meaningful history.

The Rough Edges

Git was not user-friendly. Linus built it for himself and kernel developers—people who lived in the terminal and thought in patches. The commands were cryptic. The error messages were unhelpful. The documentation assumed you already understood distributed version control.

Early Git had commands like git-update-cache instead of git add. The distinction between git reset --soft, git reset --mixed, and git reset --hard still confuses developers today. The reflog, the staging area, detached HEAD state—all were powerful features hidden behind a brutal interface.

Linus didn't care. He built Git to solve his problem, not to win popularity contests. Making it accessible was someone else's job.

The Junio Era

That someone was Junio Hamano. Three months after Git's creation, Linus handed over maintenance to Junio, a developer he trusted. Junio has maintained Git ever since—nearly two decades of steady, careful improvement.

Under Junio, Git became more usable without sacrificing power. The interface was cleaned up. Porcelain commands (the user-facing layer) were distinguished from plumbing commands (the low-level operations). Documentation improved. The learning curve remained steep, but the peak was worth climbing.

GitHub Changes Everything

Git was powerful but niche until 2008, when GitHub launched. GitHub made Git social. You could see what developers were working on, fork their projects, submit pull requests, and collaborate without exchanging email patches.

This was transformative. Open source projects migrated en masse. Companies that had never heard of Linus Torvalds started using Git because that's where their developers wanted to work. By 2020, Git had won completely. CVS was dead. Subversion was legacy. Even Microsoft—once Git's philosophical enemy—became the largest contributor to Git and hosted the largest Git repository in the world (the Windows codebase).

The Legacy of Spite

Git exists because of a licensing dispute. If Larry McVoy hadn't revoked those BitKeeper licenses, Linus might have used BitKeeper for another decade. There might never have been Git. GitHub might not exist. The modern workflow of branches, pull requests, and continuous integration might look completely different.

Sometimes the greatest innovations come from constraints. Linus didn't have time to build something perfect. He had two weeks and a problem to solve. The time pressure forced ruthless prioritization. The anger provided motivation. The result was something that fundamentally changed how software is built.

Today, Git manages the code for Linux, Windows, Android, Chrome, Firefox, and millions of other projects. It's the foundation of modern software development. And it started as a tool built out of spite, in two weeks, by a programmer who named it after himself.