The 10KB File That Beat Silicon Valley: How a Finnish Student Built Git in 2 Weeks — While Linus Torvalds Raged at BitKeeper

It was April 3, 2005. Linus Torvalds — the man who built the Linux kernel, the operating system running two-thirds of the world's servers — was about to lose the only tool that made Linux development possible.

BitMover, the company behind BitKeeper, had just revoked the free license that thousands of Linux developers relied on. The reason? Andrew Tridgell, a developer, had reverse-engineered BitKeeper's protocols. Larry McVoy, BitMover's CEO, was furious. The free ride was over.

Linus had two weeks before the kernel development process would collapse entirely.

He didn't panic. He didn't beg. Instead, he opened his email client and typed a message to the Linux kernel mailing list that would become legendary:

"I'm going to see if I can write something myself in two weeks. I already have most of the basic ideas."

That "something" became Git — the distributed version control system that now powers GitHub, GitLab, and virtually every software project on Earth. But the story of how it was built is less about code and more about rage, pride, and one man's refusal to be held hostage by proprietary software.

The BitKeeper Years: A Deal With the Devil

Before 2002, Linux kernel development was chaos.

Developers sent patches via email. Linus manually merged them. It worked when Linux had a few hundred contributors. By 2002, with thousands of developers across continents, it was unsustainable.

Then Larry McVoy offered a solution: BitKeeper.

BitKeeper was revolutionary. Unlike CVS or Subversion (the dominant tools of the era), it was distributed — every developer had a complete copy of the repository. You could commit locally, branch instantly, and merge without a central server. It was fast, powerful, and designed for exactly the kind of distributed collaboration Linux needed.

There was one catch: it was proprietary.

McVoy offered a free license to open-source projects, but with strings attached. You couldn't reverse-engineer it. You couldn't build competing tools. And McVoy could revoke the license at any time.

For Linus, it was a pragmatic compromise. "I don't like proprietary software," he said, "but I like good tools."

The deal held for three years. Until Andrew Tridgell blew it up.

The Reverse-Engineering That Started a War

Andrew Tridgell was already famous in the open-source world. He'd built Samba — the software that let Linux talk to Windows file servers — by reverse-engineering Microsoft's SMB protocol.

In early 2005, he decided to do the same thing to BitKeeper.

He wasn't trying to steal code. He wanted to understand the protocols so he could build open-source tools that interacted with BitKeeper repositories. He started by analyzing the network traffic, documenting the wire format, and building a simple client.

Larry McVoy saw it as a betrayal. BitKeeper's free license explicitly forbade reverse-engineering. Tridgell's work, in McVoy's view, was a violation of trust.

On April 3, 2005, McVoy announced that the free BitKeeper license was revoked. Effective immediately. Linux developers had two weeks to migrate — or stop using version control entirely.

Linus was livid. Not at Tridgell (though he wasn't thrilled), but at the entire situation. He'd been burned by trusting proprietary software. Now he was paying the price.

"I'll Do It Myself"

Linus didn't have time to shop for alternatives.

CVS was slow and centralized. Subversion was better but still centralized. Monotone was distributed but too slow for the kernel's scale (25,000 commits per year). There was nothing on the market that could handle Linux's workflow.

So on April 3, 2005, Linus started writing his own.

He didn't call it "Git" at first. He called it "the stupid content tracker." (Later, he joked that "Git" was British slang for "unpleasant person" — and that he named all his projects after himself.)

The first commit was 10KB of C code. It did one thing: store and retrieve file snapshots based on SHA-1 hashes.

// The first Git commit, April 7, 2005
// SHA-1: e83c5163316f89bfbde7d9ab23ca2e25604af290
static void write_sha1_file(char *buf, unsigned len)
{
    // Hash the content
    unsigned char sha1[20];
    SHA1(buf, len, sha1);
    
    // Store it in .git/objects/
    char *filename = sha1_file_name(sha1);
    write_file(filename, buf, len);
}

No branches. No merges. No network protocol. Just a content-addressable filesystem — a way to store blobs of data and retrieve them by hash.

But Linus had a vision. He knew exactly what he needed:

1. Distributed: Every developer has a full repository. No single point of failure.
2. Fast: Branching and merging must be instant, not minutes like CVS.
3. Data integrity: Use cryptographic hashes to detect corruption.
4. Simple internals: The core should be a few thousand lines of C.

He didn't care about user experience. He didn't care about learning curves. He cared about speed, correctness, and the ability to handle Linux's scale.

The Two-Week Sprint

Linus worked 16-hour days.

By April 10 (one week in), Git could:

• Add files to a repository
• Commit changes
• Show diffs between versions
• Create and merge branches

The merge algorithm was the real breakthrough. Unlike CVS (which used line-based merging and often failed), Git used a three-way merge based on the common ancestor of two branches. It was faster, smarter, and handled conflicts more gracefully.

The branching model was even more radical. In CVS or Subversion, creating a branch meant copying the entire repository — slow and expensive. In Git, a branch was just a 41-byte file pointing to a commit hash. Creating a branch took microseconds.

# A Git branch is literally just a pointer
$ cat .git/refs/heads/master
e83c5163316f89bfbde7d9ab23ca2e25604af290

By April 18 (two weeks in), Linus announced that Git could host its own development. The Linux kernel switched over the next day.

The Architecture That Changed Everything

Git's design was unconventional — and that's what made it powerful.

Most version control systems are built around files. You track main.c over time, seeing how it changed in each commit.

Git is built around snapshots. Each commit is a complete snapshot of the entire project at a moment in time. Files are stored as immutable blobs, identified by their SHA-1 hash. If a file doesn't change between commits, Git doesn't duplicate it — it just reuses the same blob.

This has profound implications:

1. Branching is free: A branch is just a pointer to a commit. Switching branches means updating a single pointer.
2. Merging is fast: Git can compute the difference between two snapshots in milliseconds.
3. History is immutable: Because every commit is identified by a hash of its content (and its parent commits), you can't change history without changing the hash. This makes tampering detectable.
4. You can work offline: Because every developer has a full copy of the repository, you can commit, branch, and merge without a network connection.

The trade-off? Storage. Git stores every version of every file. But with compression and deduplication, this turned out to be surprisingly efficient. The entire Linux kernel history (from 1991 to today) fits in about 3GB.

The Name That Stuck

Linus never intended "Git" to be the permanent name. It was a placeholder — a self-deprecating joke.

But the name stuck. Partly because Linus was too busy to rename it. Partly because the community loved the irreverence.

In the Git README, Linus wrote:

"Git can mean anything, depending on your mood:

• Random three-letter combination that is pronounceable.
• 'Global Information Tracker' if you're in a good mood.
• 'Goddamn Idiotic Truckload of sh*t' if it breaks."

By June 2005, Git was stable enough that Linus handed off maintenance to Junio Hamano, a Japanese developer who'd been contributing patches. Linus went back to the kernel. Git lived on.

The GitHub Effect

For the first three years, Git was a power user's tool. The command-line interface was arcane. The learning curve was brutal. Most developers stuck with Subversion.

Then in 2008, three developers in San Francisco — Tom Preston-Werner, Chris Wanstrath, and PJ Hyett — launched GitHub.

GitHub did something simple but transformative: it made Git social. Pull requests. Code review. Forks. Issues. Suddenly, Git wasn't just a version control system — it was a collaboration platform.

By 2018, GitHub had 100 million repositories. Microsoft acquired it for $7.5 billion. Today, Git is the default version control system for virtually every software project on Earth — from solo indie developers to Google's 2-billion-line monorepo.

The Irony

The greatest irony of Git's story is that it exists because of a licensing dispute over proprietary software.

Larry McVoy built BitKeeper to solve distributed version control. He offered it for free to open-source projects. Then when someone reverse-engineered it, he revoked the license — forcing Linus to build the very thing McVoy feared: a better, open-source alternative.

If McVoy had never revoked the license, Git might not exist. Linux developers might still be using BitKeeper. GitHub might never have been founded.

Instead, by trying to protect his proprietary software, McVoy inadvertently sparked the creation of the tool that made proprietary version control obsolete.

The Legacy

Today, Git is infrastructure. It's invisible. Developers don't think about it — they just use it.

But the engineering decisions Linus made in those two weeks still shape how millions of developers work:

• Distributed > Centralized: Git proved that distributed systems are more resilient, more flexible, and faster than centralized ones. This philosophy influenced everything from blockchain to peer-to-peer systems.
• Content-addressable storage: Git's use of SHA-1 hashes to identify objects inspired systems like IPFS, Docker images, and even package managers like Nix.
• Branching as a first-class feature: Git normalized the idea that branching should be instant and merging should be automatic. This enabled modern workflows like GitHub Flow and GitLab Flow.

Linus built Git in two weeks out of necessity. But he built it with principles that have lasted 20 years:

Fast. Simple. Distributed. Correct.

And he did it all while being furious at a licensing dispute.

Sometimes the best software is born from spite.