Two Weeks to Change Software Forever

A Sunday in Portland

April third, two thousand five. A Sunday. Linus Torvalds wakes up in his home in Portland, Oregon, and decides to build a new version control system.

This isn't a carefully planned project. There's no design document. No team meetings. No roadmap. Just Linus, angry about the BitKeeper situation, convinced he can do better, and apparently with nothing else to do on a Sunday.

He'll call it Git, a piece of British slang for an unpleasant person, chosen with the same self-deprecating arrogance he brought to naming Linux. He would later explain, with a grin, that he names all his projects after himself.

Let's be clear about what he's attempting here. Version control systems are complex pieces of software. Teams of engineers spend years building them. CVS took years to mature. Subversion was in development for years before its one-point-oh release. BitKeeper was a commercial product with a full-time development team.

Linus is one guy with a weekend.

Tuesday: It Tracks Files

By Tuesday, April fifth, Git can track files and compute diffs. It's not pretty, but it works.

Thursday: It Tracks Itself

By Thursday, April seventh, four days after he started, Git is self-hosting. He's using Git to track Git's own development. The tool is managing its own source code.

By April sixteenth, two weeks in, the Linux kernel starts migrating to Git. The biggest open source project in the world is now betting on a two-week-old version control system built by one person.

This shouldn't have worked. This is insane. But it did work, and twenty years later, Git runs the world.

So what happened in those two weeks? And why did Linus's choices then still matter today?

Design for Speed

Linus had one overriding principle: speed. Everything else was secondary.

CVS and Subversion were slow. Painfully slow. Checking the status of a large project in Subversion could take minutes because it had to contact the server and compare your local files against the remote repository. Branching and merging were operations you'd do rarely because they were expensive.

Linus wanted Git operations to be instantaneous. Not "pretty fast." Not "fast enough." Instantaneous.

Why? Because if operations are fast, you'll use them more. You'll commit more often because committing is instant. You'll branch freely because creating a branch takes microseconds. You'll experiment without fear because reverting is instant.

If you can do something really fast, really well, people will start using it differently.

Fast tools change behavior. Slow tools constrain it.

So Linus made some radical choices. Git would store everything locally. Your complete history, every branch, every commit, all on your machine. No network round-trips for basic operations. Want to see the diff between two commits from six months ago? Instant. Want to create a branch? Instant. Want to commit changes? Instant.

The only time you need a network is when you're sharing with others. Everything else happens on your machine at disk speed.

This seems obvious now, but in two thousand five, it was weird. Developers were used to centralized systems. The "real" repository was on a server somewhere. Your local machine just had a working copy.

Git flipped that model. Every Git repository is real. Every clone is complete. There's no "central" repository in Git's design, that's just a social convention teams adopt. Technically, every copy is equal.

The Content-Addressed Store

Here's where Git gets clever. Instead of storing files by name, Git stores them by content.

When you add a file to Git, it doesn't save it by its filename. Instead, Git runs the file content through a mathematical function called a hash, which generates a unique forty-character string based on the content. That string is the file's fingerprint. The same content always produces the same fingerprint. Change even one character, and you get a completely different fingerprint.

This approach has some beautiful properties. If two files have identical content, they get the same fingerprint, so Git only stores them once. If a file gets corrupted, a bit flip on disk or a network error, the fingerprint won't match anymore. Git will know something's wrong. It's not just version control; it's also a verification system.

Every single piece of data, when Git tracks your content, we compress it, we delta it against everything else, but we also do a hash of the content, and we actually check it when we use it.

Torvalds said that during his two thousand seven Google Tech Talk, and the point was fundamental. Every piece of content gets a fingerprint. Every directory gets a fingerprint of its contents. Every commit is a snapshot that points to the state of everything and links back to the previous snapshot. That chain of snapshots is your history. Git calls itself a "content-addressable filesystem," and it means it literally. At its core, it is a key-value store where the keys are fingerprints and the values are compressed file contents. Everything else, branches, merges, remote collaboration, is built on top of this simple foundation. We will dig deeper into these internals next episode.

Branches Are Cheap

Here's where Git really diverges from CVS and Subversion.

In Git, a branch is just a pointer. A tiny file containing one commit fingerprint. That is it. Creating a branch does not copy files, does not duplicate the repository, does not even talk to the disk much. It is essentially instant regardless of repository size. Compare this to Subversion, where creating a branch meant copying the entire project directory on the server. Want a branch of your five hundred megabyte repository? Wait while Subversion copies five hundred megabytes of data. No wonder people avoided branching.

Git's cheap branching changed development workflows. Suddenly you could create a branch for every feature or bug fix. Experiment freely, knowing you can throw away branches instantly. Maintain multiple parallel lines of development. Switch between branches dozens of times a day.

This sounds simple, but it was revolutionary. Tools shape behavior. When branching is free, people branch. When branching is free, people experiment. When experimentation is free, innovation accelerates.

The Quiet Steward

On July twenty-sixth, two thousand five, less than four months after Git's birth, Linus makes a surprising announcement. He's stepping back as Git's maintainer. Junio Hamano, a kernel developer at Google, will take over.

This might seem like an odd move. Linus created Git. It's his vision, his design. Why hand it off so quickly?

The answer is characteristically pragmatic. Linus is a kernel developer, not a version control tool developer. He built Git because he needed it, and he built it fast. But maintaining a popular open source project is a different job. It requires patience, communication, handling bug reports, reviewing patches, making incremental improvements.

I'm not dropping Git, I just prefer working on it as a contributor rather than trying to keep track of everything.

Linus is, by his own admission, not great at those things. Junio is.

So Git got a new maintainer, and Linus went back to working on the Linux kernel. Using Git, of course.

Junio has been Git's maintainer ever since. Twenty years. While Linus gets credit for creating Git, rightfully so, Junio deserves credit for making it usable, stable, and successful. Linus provided the brilliant, furious spark of creation. Junio's steady stewardship provided the oxygen that let the fire burn.

This transition is rare in open source. Most projects either stick with their original creator until they burn out or die with them. Git got the best of both worlds. We will follow Junio's thread throughout this series, because the twenty-year maintainer is as much a part of this story as the two-week creator.

Why This Design Still Matters

Linus made these design decisions in April two thousand five because he needed speed and reliability for kernel development. But those decisions have ripple effects twenty years later.

Content-addressing means Git can detect corruption and verify integrity. This becomes crucial for supply chain security and build reproducibility.

Local-first means you can work offline. On a plane. In a coffee shop with sketchy wifi. When GitHub goes down. Your repository is with you, always.

Cheap branching enables modern development workflows. Feature branches, pull requests, continuous integration, all of this works because branches are free.

Distributed architecture means every clone is a backup. If GitHub disappeared tomorrow, millions of repositories would survive because they're all fully replicated.

If you're not distributed, you are not worth using. It's that simple.

Linus wasn't thinking about these use cases in two thousand five. He just wanted something fast and reliable for kernel development. But good design has emergent properties. The features you build for one reason turn out to be useful for reasons you never anticipated.

That's the magic of Git. It's not just that it works. It's that it works in ways its creator never imagined, solving problems that didn't exist yet when it was built.

Two weeks to change software forever. Not bad for a Sunday project.

Every Git repository starts the same way. git init. Two words. Git creates a hidden folder called dot git inside your current directory, and that folder contains everything. The entire version control system for your project. No server involved. No account to create. No connection required. Just a folder on your disk. Inside it, a handful of subdirectories: objects for every version of every file, refs for branches and tags, and a file called HEAD that knows which branch you are on. That is the entire architecture. When Linus designed Git, he wanted it to work without a network, without a central server, without permission from anyone. git init is that philosophy in two words. You run it, and you own your history.