The Licensing Fight That Saved the Internet: How a Lawyer's Email Forced Linus Torvalds to Create Git in Two Weeks

The Email That Changed Everything

It was April 6, 2005. Linus Torvalds opened an email that made his blood run cold.

Larry McVoy, CEO of BitMover and creator of BitKeeper — the version control system that had managed Linux kernel development for the past three years — was pulling the plug. Effective immediately. The free license that had allowed thousands of kernel developers to collaborate was being revoked.

The reason? Andrew Tridgell, a brilliant Australian programmer (famous for creating Samba), had reverse-engineered BitKeeper's protocols. McVoy saw this as a betrayal. The carefully negotiated peace that had kept Linux development humming along was over.

Linus had 72 hours before kernel development would effectively freeze.

He had two options: find another version control system that could handle the Linux kernel's scale and complexity, or build one himself.

Every existing tool was inadequate. CVS was ancient and centralized. Subversion was slow and couldn't handle branching properly. Perforce was proprietary. Nothing could handle thousands of developers working on millions of lines of code with the speed and reliability Linux demanded.

On April 7, 2005, Linus made an announcement on the Linux kernel mailing list that would change software development forever:

"I'm going to see if I can design something myself that actually works."

He gave himself two weeks.

The Impossible Requirements

Linus wasn't just building a version control system. He was building one that had to be fundamentally different from everything that existed.

His requirements were brutal:

Speed, or it's useless. The Linux kernel had 17,000 files and millions of lines of code. Operations that took minutes in CVS or Subversion had to take seconds. "Take CVS as an example of what not to do," Linus wrote. "If in doubt, make the exact opposite decision."

Distributed, or developers revolt. No central server that could become a bottleneck or single point of failure. Every developer needed a complete copy of the entire repository history on their laptop. This was considered insane in 2005.

Handle branching like breathing. In existing systems, creating a branch was an event. A big deal. Something you planned. Linus wanted branching to be so cheap and fast that developers did it constantly, experimentally, fearlessly.

Verify everything cryptographically. Every piece of code needed to be checksummed with SHA-1. If a single bit corrupted anywhere in the history, Git would know immediately. Trust nothing.

Assume everyone's an idiot (including yourself). The system had to protect developers from their own mistakes while being impossible to accidentally corrupt.

Oh, and one more thing: it had to be operational in two weeks, because that's when the next kernel merge window opened.

The First Commit

Linus started coding on April 7th.

He didn't write Git in C initially. He started with simple shell scripts and Perl. The first version was barely 1,200 lines. It was ugly, minimal, and laser-focused on the core problem: storing and retrieving file snapshots with cryptographic integrity.

The architecture was radical. Instead of tracking changes (like CVS or Subversion), Git stored complete snapshots. Every commit was a complete picture of every file at that moment, linked together in a directed acyclic graph and identified by SHA-1 hashes.

This seemed wasteful. "You're going to store the entire file every time?!" critics asked.

But Linus understood something others didn't: disk space was cheap and getting cheaper. What was expensive was complexity. By storing snapshots and using clever compression, Git could be blazingly fast and conceptually simpler.

On April 7, 2005, at 15:13:47 Pacific Time, Linus made the first commit to Git:

commit e83c5163316f89bfbde7d9ab23ca2e25604af290
Author: Linus Torvalds <torvalds@ppc970.osdl.org>
Date:   Thu Apr 7 15:13:47 2005 -0700

    Initial revision of "git", the information manager from hell

The commit message was classic Linus: self-deprecating, slightly profane, and completely confident.

The Two-Week Sprint

What happened over the next 14 days was one of the most concentrated bursts of creative programming in tech history.

Linus barely slept. He was possessed by the problem. His wife, Tove, would later joke that she considered leaving him during those two weeks — not because he was absent, but because even when he was physically present, his mind was somewhere else entirely, thinking about Merkle trees and object databases.

By April 10th — three days in — Git could already do the basics: add files, commit changes, and compute diffs. Linus used Git to manage Git's own source code from day four.

By April 18th, Git performed its first real test: managing a merge between different Linux kernel branches. It worked.

By April 20th, Git was managing its own development and Linus had started migrating Linux kernel history into it.

On April 29th — 22 days after the BitKeeper implosion — Linus sent an email to the kernel mailing list:

"Ok, this is the real deal. Git can now do a full kernel merge."

He had done it. In two weeks, he'd built a version control system that could handle the most complex software project on the planet.

The Architecture That Won

What made Git different wasn't just speed. It was a fundamentally different mental model.

Every other version control system was built around the question: "What changed?" They stored files and then tracked deltas — the differences between versions.

Git asked a different question: "What does the world look like now?" It stored snapshots and figured out differences on the fly.

This inversion seemed backwards, but it unlocked everything:

Branches became free. Creating a branch in Subversion meant copying entire directory trees. In Git, it was just creating a 41-byte file containing a SHA-1 hash. Instant. Costless.

Merging became intelligent. Git didn't just track what changed in two branches. It tracked the common ancestor and used that to make merging dramatically smarter.

Everything was local. Want to view history? Instant. Create a branch? Instant. Commit changes? Instant. No network latency, ever.

Trust was cryptographic. The entire history of a repository could be verified with a single hash. If someone tampered with an old commit, every subsequent hash would change. Impossible to fake.

The architecture was so good that it became the standard. GitHub launched in 2008, built entirely around Git. By 2024, over 100 million developers use Git. Microsoft abandoned its own system and moved Windows development to Git. Google built its own clone of Git's architecture.

The Irony Nobody Expected

Here's the twist: Linus built Git out of anger and necessity. He didn't set out to revolutionize version control. He just needed to solve an immediate problem so he could get back to working on the Linux kernel.

He maintained Git himself for exactly four months.

In July 2005, he handed over maintainership to Junio Hamano, a Japanese developer who had been contributing patches. Linus wanted to get back to kernel work.

"I'm not a version control expert," Linus said later. "I just knew what was wrong with everything else."

That handoff was one of the best decisions Linus ever made. Junio transformed Git from a brilliant prototype into production-grade software. He added the porcelain — the user-friendly commands people actually use. He fixed rough edges. He made Git not just powerful, but usable.

Linus's two-week sprint created the architecture. Junio's decade of stewardship made it ubiquitous.

The Legacy

Today, Git is invisible infrastructure. It's like plumbing — nobody thinks about it until it breaks, and it almost never breaks.

But its impact is staggering:

Open source exploded. Git made forking and contributing to projects so easy that it catalyzed the modern open source movement. GitHub, GitLab, and Bitbucket wouldn't exist without it.

Development workflows transformed. Pull requests, feature branches, continuous integration — the entire modern software development process is built on Git's model of cheap branching and easy merging.

Distributed development became default. Before Git, having 100 developers in different time zones work on the same codebase was logistically nightmarish. Git made it routine.

The industry standardized. For the first time in computing history, there's near-universal agreement on a fundamental tool. From solo indie developers to Microsoft's Windows team, everyone uses Git.

All because a lawyer sent an email that pissed off Linus Torvalds.

The BitKeeper licensing fight that seemed like a disaster in April 2005 turned out to be the best thing that ever happened to version control. Larry McVoy's decision to pull the plug inadvertently forced the creation of the tool that would make his own product obsolete.

Linus Torvalds is famous for creating Linux, the operating system that runs most of the internet. But his second act — building Git in a furious two-week sprint — might be equally important.

Because Git didn't just change how we store code. It changed how we think about collaboration, history, and trust.

And it all started with an angry programmer who had two weeks to solve an impossible problem.

He didn't just solve it. He built something that will outlive us all.