The Licensing Fight That Gave Us Git: How Linus Torvalds Built Version Control in Two Weeks Out of Spite

April 3, 2005. Linus Torvalds stared at his email with the kind of quiet fury that precedes revolution.

Larry McVoy, CEO of BitMover, had just pulled the plug. The free license that let the Linux kernel team use BitKeeper — the version control system they'd relied on for three years — was gone. Revoked. Done. The reason? Andrew Tridgell, a Samba developer, had reverse-engineered BitKeeper's protocols. McVoy saw it as a betrayal. Torvalds saw it as a catastrophe.

Thousands of developers worldwide depended on the Linux kernel. Without version control, coordinating changes across that distributed army would be chaos. CVS was a dinosaur. Subversion was centralized garbage. Commercial alternatives cost money the open-source community didn't have.

Linus had two weeks before the next kernel release cycle. He could spend that time evaluating alternatives, begging for licenses, rallying the community for solutions.

Instead, he decided to write his own version control system from scratch.

What happened next would accidentally create the tool that now hosts over 100 million repositories and powers virtually every major tech company on Earth.

The Rant That Started Everything

Linus didn't ease into this decision. On April 6, three days after the BitKeeper axe fell, he sent an email to the Linux kernel mailing list that read less like a technical announcement and more like a declaration of war against bad software.

"I'm going to see if I can write something myself," he wrote, "that does at least the basic stuff (pull/commit/diff/log) in the time we have until the next kernel release."

Basic stuff. Two weeks. Oh, and it had to be better than everything else that existed.

His requirements were characteristically blunt and uncompromising:

• Fast. Not "pretty fast" or "fast enough." BitKeeper-fast, which meant operations in milliseconds, not minutes.
• Distributed. Every developer needed a complete copy. No central servers to become bottlenecks or single points of failure.
• Trustworthy. Cryptographic guarantees that history couldn't be corrupted, accidentally or maliciously.
• Simple architecture. The design had to be so straightforward that Linus could explain it while drunk (his actual criterion).

Most software engineers would look at that list and budget six months. Linus gave himself a fortnight.

The Two-Week Sprint

What followed was one of the most concentrated bursts of engineering productivity in software history.

Linus started on April 6. By April 7 — one day later — he had a self-hosting version. Git could track its own development. He announced this on the mailing list with characteristic modesty: "I'm doing a (free) source control management system."

The name? "Git" — British slang for a stupid or unpleasant person. Linus called it "the stupid content tracker." When asked about the name, he said, "I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git."

By April 20 — fourteen days after starting — Git performed its first-ever merge of multiple development branches into the Linux kernel tree. The most complex operation in version control, working flawlessly, built in two weeks.

How?

The Architecture That Broke All the Rules

Linus didn't build Git the way everyone else built version control systems. He started with a radical insight: version control isn't about files. It's about content.

Every other system tracked files across time — version 1 of main.c, version 2 of main.c, and so on. Git tracked snapshots of entire project states, using cryptographic hashes (SHA-1) to identify each unique piece of content.

This sounds abstract until you see what it enables:

Speed: Because Git hashes content, it knows instantly whether two files are identical without comparing them byte-by-byte. Massive operations become trivial.

Distribution: Because every clone contains the full history, you can work offline, branch freely, and merge later. No central server needed.

Integrity: Because every commit is cryptographically signed based on its parents and content, you can't change history without everyone knowing. The entire tree is tamper-evident.

The data structure was elegantly simple: blobs (file contents), trees (directories), commits (snapshots), and tags (labels). That's it. Four object types. A first-year CS student could understand the model.

But the implications were profound.

The Part Linus Didn't Build

Here's the twist: Linus built Git so fast because he didn't build a user interface.

The original Git was a collection of shell scripts and C programs with names like git-write-tree, git-commit-tree, and git-cat-file. Using it required typing commands like:

cat | git-hash-object -w --stdin
git-update-index --add --cacheinfo 100644 <hash> filename

It was powerful. It was fast. It was also completely unusable by anyone except Linus.

Junio Hamano, a Japanese developer working at Google, saw the potential. Starting in July 2005, Hamano began building what Git desperately needed: a coherent interface, proper documentation, and the polish that would make it usable by mortals.

By December 2005, Linus handed over maintainership to Hamano. "Junio is a lot better at the day-to-day maintenance," Linus said. "I got bored with it."

Classic Linus. Build something revolutionary in two weeks, get bored, hand it off, move on.

The Moment It Clicked

Git spent its first few years in the wilderness. It was fast, powerful, and baffling. Developers complained about the learning curve. Subversion advocates mocked its complexity. "Why would anyone need distributed version control?" they asked.

Then came GitHub.

In October 2007, three developers — Tom Preston-Werner, Chris Wanstrath, and PJ Hyett — launched GitHub at a San Francisco sports bar. They built a beautiful web interface on top of Git's ugly plumbing. Suddenly, creating repositories, viewing diffs, and collaborating with strangers became delightful.

GitHub's growth was exponential. By 2009, it hosted 100,000 repositories. By 2013, it reached 10 million. Today, over 100 million.

The tool Linus built in a fury became the substrate of modern software development.

The Hidden Consequences

Git changed more than version control. It changed how software gets built.

Open source exploded. Forking a project went from a hostile act requiring server access to clicking a button. Contributing went from emailing patches to opening pull requests. Collaboration became frictionless.

Development accelerated. Branching became cheap, so developers experimented freely. Merging became reliable, so teams could work in parallel. Code review became standard, so quality improved.

Large-scale coordination became possible. The Linux kernel receives over 10,000 commits per release from hundreds of developers worldwide. Windows, macOS, Chrome, Android — every major software project uses Git or its descendants.

Even Microsoft, which spent decades pushing its own version control systems, capitulated. In 2017, they moved Windows development to Git (with custom modifications to handle a 300GB repository). In 2018, they bought GitHub for $7.5 billion.

The company that personified proprietary software paid seven billion dollars for a platform built on a tool created in two weeks by a Finnish developer who named it after himself.

The Legacy

Linus never intended to build Git long-term. He wanted to solve an immediate problem: losing access to BitKeeper. He succeeded so well that he accidentally created infrastructure.

Today, Git is maintained by Hamano and dozens of contributors. Linus occasionally weighs in but spends most of his time on Linux. When asked about Git's success, he shrugs: "I'm not a huge git fan. I think it's a reasonable version control system, but I have no emotional attachment to it."

The man who built the tool that powers modern software development finds it... reasonable.

But here's what makes the Git story profound: the best tools often come from spite, not planning.

Linus didn't convene committees or write specifications. He didn't do market research or competitive analysis. He got angry at bad software, spent two weeks building something better, and moved on.

That scrappy, rage-driven project now has more daily users than BitKeeper ever dreamed of. It outlasted Subversion, crushed Mercurial, and became so dominant that "version control" and "Git" are nearly synonymous.

All because someone revoked a license and pissed off exactly the wrong Finnish programmer.

The next time you git push, remember: you're using a tool built in two weeks by a guy who named it "stupid" and got bored with it six months later.

And somehow, that's exactly why it works.