The Scars of War: Why Linus Torvalds Created Git

💡 TL;DR (Too Long; Didn't Read)

In April 2005, a corporate war between Linus Torvalds and Larry McVoy (BitMover CEO) left Linux kernel development without a version control system. In just 10 days, Linus created Git to solve a problem that had plagued software development for decades: how thousands of developers can efficiently collaborate on a massive project without a central point of failure. Git wasn't just a technical solution - it was a philosophical revolution that forever changed how the world develops software.

April 2005. The world of software development was about to change forever, but nobody knew it yet.

Linus Torvalds, the creator of Linux, was facing a crisis that threatened to paralyze development of the world's most important kernel. It wasn't a critical bug or security flaw. It was something much worse: a political war that would leave thousands of developers without the tools they needed to collaborate.

This is the true story of how ten days of frustration and genius created the tool that today governs almost all modern software development.

The Problem Nobody Could Solve

To understand why Git was revolutionary, we need to go back to the 90s and understand the hell that was version control before it existed.

CVS: The Stubborn Dinosaur

The Concurrent Versions System (CVS) dominated the version control world, and it was daily torture for any serious developer. Imagine working like this:

Atomic commits? Didn't exist. If you modified 5 files and one failed mid-commit, you'd end up with a repository in an inconsistent state.
Renaming files was a nightmare. CVS didn't track file movements - you'd lose all history.
Branches were expensive and slow. Creating a branch meant physically copying all files.
Merge? Good luck. Merge tools were primitive, and complex conflicts became epic battles.

bash

# An "atomic" commit in CVS - which wasn't really atomic
cvs add file1.c file2.c file3.c
cvs commit -m "Adding new feature"
# If file2.c failed, you'd end up with a partial commit
# No easy way to revert

Subversion: The Evolution Attempt

Subversion (SVN) came promising to solve CVS's problems. And it really did solve some:

Real atomic commits
Directory versioning
Richer metadata

But it maintained the original sin: centralized architecture. Every developer depended on a central server. If the server went down, development stopped. If the network was slow, every operation became a painful wait.

bash

# In SVN, these required server access
svn log    # Network
svn diff   # Network
svn blame  # Network
svn branch # Network (and expensive!)

For Linux kernel development, with thousands of developers scattered around the world, this was unsustainable.

The BitKeeper Era: Love and Hate

In 2002, Linus made a controversial decision that divided the open source community: he adopted BitKeeper, a commercial distributed version control system.

Why BitKeeper Was Special

BitKeeper revolutionized Linux development because it introduced concepts we now consider obvious:

Distributed by design: each clone was a complete repository
Smart merge: sophisticated algorithms to resolve conflicts
Performance: local operations were instantaneous
Cheap branches: creating a branch was a matter of seconds

bash

# In BitKeeper, these were all local and instantaneous
bk log     # Local
bk diff    # Local
bk blame   # Local
bk clone   # Created a complete repository

The Faustian Deal

But there was a price. Larry McVoy, BitMover CEO, offered free licenses to Linux kernel developers, with one condition: they couldn't work on competing version control systems.

It was a smart deal for BitMover - they got showcasing of the world's most visible open source product, while preventing the community from creating alternatives.

The Spark That Ignited Everything

In April 2005, the tension exploded. Andrew Tridgell, one of the Samba developers, began reverse engineering the BitKeeper protocol to create interoperability tools.

Technically, Andrew wasn't violating the license terms. But Larry McVoy saw this as a direct affront and made the decision that would change software history:

He revoked all free BitKeeper licenses for Linux development.

The Ultimatum

Larry wasn't bluffing. In a direct email to Linus, he was clear: "You have until the end of the month to migrate to another solution. The party's over."

Linus found himself facing an impossible dilemma:

Go back to CVS/SVN: Unthinkable. It would be a catastrophic technical regression.
Pay for the license: Philosophically incompatible with the Linux project.
Find an alternative: Nothing on the market was up to BitKeeper's standard.
Create something new: In how much time? With what resources?

The 10 Days That Changed the World

Linus Torvalds wasn't just a brilliant programmer - he was a systems architect with a clear vision of what needed to be done. He established three non-negotiable principles for any solution:

Speed Above All

"CVS takes 30 seconds to show a file's history. That's unacceptable." - Linus Torvalds

Linus knew developers abandon slow tools. If something takes more than a few seconds, it breaks the flow of thought.

Conceptual Simplicity

The system should be simple to understand, even if the implementation was complex. Developers needed to form a clear mental model of how things worked.

Robust Non-Linear Development

Linux had thousands of developers working on parallel branches. The system needed to make merge and branching trivial operations, not epic battles.

The Heroic Implementation

On April 3, 2005, Linus began programming. Not a specification or design document - straight code, in C, solving the most fundamental problems first.

Day 1-3: The Object Database

// The first genius: everything is a SHA-1 identified object
// Files, directories, commits - everything becomes hash
struct object {
    unsigned char sha1[20];
    unsigned int type;
    void *data;
    unsigned long size;
};

Day 4-6: Basic Operations

bash

# April 6 - first commands working
git-init-db        # Creates repository
git-update-cache   # Adds files
git-write-tree     # Creates tree object
git-commit-tree    # Creates commit

Day 7-10: The Miracle On April 7, Linus managed to use Git to version his own source code. On April 10, he made the most important commit in software history:

commit e83c5163316f89bfbde7d9ab23ca2e25604af290
Author: Linus Torvalds <[email protected]>
Date:   Thu Apr 7 15:13:13 2005 -0700

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

The Genius of the Architecture

What Linus created in 10 days wasn't just functional code - it was an architecture fundamentally different from anything that existed.

Content-Addressable Storage

bash

# Each object is identified by the hash of its content
echo "Hello, World!" | git hash-object --stdin
# a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3

# If content is identical, hash is identical
# Automatic deduplication!

Immutable Objects

Once created, a Git object never changes. This brings powerful consequences:

Integrity: Corruption is detected instantly
Caching: Objects can be cached infinitely
Concurrency: Multiple processes can access without locks

Distributed by Design

Unlike BitKeeper, which was distributed but still thought in terms of "central repository," Linus completely eliminated this concept:

bash

# There's no technical difference between these repositories
git clone /path/local/repo
git clone user@server:/path/remote/repo
git clone https://github.com/user/repo

# All are complete and equivalent repositories

The Philosophy Behind the Code

Linus wasn't just solving technical problems - he was creating a new development philosophy.

"Information Manager from Hell"

The name "Git" (which means "idiot" in British English) and the subtitle "information manager from hell" reveal Linus's irreverent personality, but hide a deep philosophy:

Git doesn't manage "files" or "versions" - it manages information and relationships between information.

Trust Nothing, Verify Everything

bash

# Each commit points to the previous commit via SHA-1
git log --oneline --graph
# * 2f1e2b3 (HEAD -> main) Latest changes
# * a4b5c6d Previous commit
# * 1a2b3c4 Initial commit

# If any bit changes anywhere in history,
# all subsequent hashes change
# Corruption or tampering are impossible to hide

Cheap Branches, Expensive Nothing

Linus understood branches shouldn't be "special features" - they should be the natural way to work:

bash

# Create a branch: 41 bytes in .git/refs/heads/
git branch feature-xyz    # Instantaneous

# Switch branches: updates working directory
git checkout feature-xyz  # Seconds, not minutes

# Branch is just a pointer to a commit
# Extremely cheap, extremely fast

The Immediate Impact

Linux Kernel Adoption

On June 16, 2005 - just two months after the start - Linus officially migrated Linux kernel development to Git. The transition was surprisingly smooth.

Revealing performance:

CVS: cvs log on kernel = 30+ seconds
Git: git log on kernel = <1 second
BitKeeper: equivalent operation = 5-10 seconds

Industry Reaction

The technical community was divided between skepticism and admiration:

Skeptics: "Another version control system. How many have we had?"

Visionaries: "This will change everything. The architecture is fundamentally different."

The visionaries were right.

Why Did Git Win?

Undeniable Performance

bash

# Real comparison in 2005 (Linux kernel repository):

# CVS
time cvs log kernel/sched.c
# real: 0m45.2s  # More than 45 seconds!

# SVN
time svn log kernel/sched.c
# real: 0m12.8s  # Improvement, but still slow

# Git
time git log kernel/sched.c
# real: 0m0.3s   # Less than half a second!

Correct Mental Model

Git forces you to think correctly about version control:

Snapshots, not deltas: Each commit is a complete state
DAG, not line: History is a directed acyclic graph
Local first: Local operations are primary, network is secondary

Smart Merge

Git's 3-way merge algorithm, inherited from BitKeeper concepts but reimplemented, was far superior to previous systems:

bash

# Git can automatically resolve cases that
# left CVS/SVN confused
git merge feature-branch
# Auto-merging common.c
# Merge made by the 'recursive' strategy.

Distributed Workflows

Git didn't prescribe workflows - it allowed teams to create their own:

bash

# Centralized workflow (like SVN)
git push origin main

# Fork/pull-request workflow
git push fork feature-branch

# Hierarchical workflow
git push lieutenant subsystem-branch

The Scars That Became Strength

Lessons from BitKeeper

Linus learned from the BitKeeper experience:

Never depend on a company for critical tools
Open source from day zero
Performance is non-negotiable
Conceptual simplicity is crucial

Design Decisions That Endure

Why SHA-1 (at the time)?

Cryptographically secure (in 2005)
160 bits = 20 bytes = compact representation
Collisions astronomically unlikely for practical use
Instant corruption detection

Why everything immutable?

Easier debugging (states don't change)
Concurrency without locks
Aggressive caching possible
Guaranteed integrity

Why local operations?

Constant speed independent of network
Natural offline work
Implicit backup in each clone

The Enduring Legacy

Paradigm Shift

Git wasn't just a better tool - it was a fundamental change in how we think about code:

Before Git:

Code lives on the server
Developers checkout parts
Conflicts are problems to avoid
Branches are expensive and rare

After Git:

Code lives everywhere
Developers have complete history
Conflicts are discussion opportunities
Branches are natural workflows

Enabling the Open Source Revolution

Git made projects like these possible:

GitHub (2008): Social coding for the masses
Android (2008): World's most used mobile system
Kubernetes (2014): Container orchestration
React (2013): Most popular web library

All these projects would be impractical without Git's distributive capabilities.

Influence on Other Tools

Git's model influenced systems far beyond version control:

Docker: Immutable layers identified by hash
Blockchain: Immutable data structures linked by hash
IPFS: Content-addressable storage for the web
Nix: Functional package manager with cryptographic integrity

Conclusion: The War That Saved Software

The war between Linus Torvalds and Larry McVoy in 2005 seemed, at the time, a petty dispute between technical egos. In reality, it was the necessary catalyst for creating the most important tool of modern development.

The scars left by years of frustration with CVS, SVN, and even BitKeeper dependence became the driving force to create something truly revolutionary. Git wasn't just a response to an immediate problem - it was a complete reimagining of how software should be developed.

Today, when you do a git commit, you're using the architectural principles Linus established in 10 furious days in April 2005. When millions of developers collaborate on gigantic projects without conflict, they're experiencing the vision that was born from the most urgent necessity.

Git proved that some of the best solutions are born not from the luxury of time, but from the pressure of necessity. And that sometimes, a war is exactly what the world needs to evolve.

"Talk is cheap. Show me the code." - Linus Torvalds

In 10 days, he showed the code that would change the world.

✨TL;DR / Executive Summary

Receive new articles