Git Released — Torvalds Writes Distributed Version Control in Ten Days

On 3 April 2005, Linus Torvalds began designing a new version-control system. On 7 April the first commit landed—e83c516, "Initial revision of 'git', the information manager from hell"—and Git began tracking its own source. On 16 April the Linux kernel tree itself (2.6.12-rc2, 6,718,755 lines) went in as commit 1da177e. The first kernel release actually managed by Git was 2.6.12 on 16 June.

Thirteen days from design start to the kernel import. Torvalds' own summary: "it was about 10 days until I could use it for the kernel" (GitHub Blog, 2025). Few episodes in software engineering history match that velocity.

Why was it possible at all, and why did Git displace every prior VCS—CVS, Subversion, Perforce, BitKeeper—and become the world standard? The answer lies in what happened during those few weeks in April 2005.

The BitKeeper Crisis

From 2002 to 2005, Linux kernel development ran on BitKeeper, a commercial distributed VCS developed by BitMover. BitMover granted free licences for open-source use. "We've been using BK for three years," Torvalds wrote in the post that ended the arrangement.

Torvalds had chosen BitKeeper for a simple reason: every open-source VCS of the time (CVS, Subversion) was centralised and could not handle the scale of Linux kernel development—thousands of contributors in parallel. BitKeeper was the only realistically distributed option.

In April 2005 the arrangement broke. OSDL's Andrew Tridgell (of Samba fame) built a client that recovered the revision metadata BitKeeper's free version would not show. The free version's licence barred its users from taking part in the development of a competing SCM; Tridgell probed the protocol without agreeing to that licence at all.

BitMover announced it would stop supplying the free version, citing Tridgell's work as the reason. It offered free commercial licences to some kernel developers, but not to OSDL employees—which meant not to Torvalds and not to Andrew Morton. Support formally ended on 1 July 2005.

On 6 April 2005 Torvalds posted "Kernel SCM saga.." to LKML. On where the blame lay he was explicit: "Btw, don't blame BitMover, even if that's probably going to be a very common reaction. Larry in particular really did try to make things work out." And the postscript recorded exactly how he rated the alternatives: "Don't bother telling me about subversion. If you must, start reading up on 'monotone'."

Specifications Written in Ten Days

The ten days were not a sprint from a standing start. "It all depended on getting the basic ideas right. And that I had been mulling over for a while before the whole project started," Torvalds told the Linux Foundation in 2015; in 2025 he dated the start of that mulling to the previous November or December. By the time he wrote code, the specification was already in his head.

The Git project's own account of the original design goals lists five:

1. Speed
2. Simple design
3. Strong support for non-linear development (thousands of parallel branches)
4. Fully distributed — all repositories are peers, no central server
5. Able to handle large projects like the Linux kernel efficiently, in both speed and data size

What the fifth goal meant in practice is visible in the 16 April import: 6,718,755 lines added in a single commit.

The pivotal choice was content-addressable storage. The first README puts it plainly: "The object database is literally just a content-addressable collection of objects. All objects are named by their content, which is approximated by the SHA1 hash of the object itself." "Address" means "what is inside", not "what it is called". Identical content is automatically deduplicated. The integrity of history is mathematical, not procedural.

"The Stupid Content Tracker"

The first line of the first README reads "GIT - the stupid content tracker". Torvalds then explains that "git" means whatever your mood requires: "stupid. contemptible and despicable. simple"; on a good day "global information tracker"; when it breaks, "goddamn idiotic truckload of sh*t".

The trust model is spelled out in the same file: "'git' itself only handles content integrity, the trust has to come from outside." The hashes prove nothing has been altered; whether the history deserves belief is settled outside Git, by a signed tag or a signed mail naming a top commit.

The earliest Git did not have a friendly CLI. It was a collection of low-level commands (the "plumbing")—git commit-tree, git update-ref, git read-tree—that manipulated internal data structures directly.

The friendlier upper-level commands (the "porcelain")—git commit, git checkout, git merge—were built up from mid-2005, led by Junio Hamano. On 26 July 2005 Torvalds handed the maintainer role to Hamano. For more than twenty years since, Hamano has remained the principal Git maintainer.

Why Git Won

In 2005, other distributed VCSes existed:

• Mercurial (Hg) — started by Matt Mackall around the same time, with a similar design
• Monotone — 2003; a precedent for content addressing, and the only alternative Torvalds named as promising in his 6 April post
• Darcs — public release 2003 (work from 2002); based on patch theory but slow
• Bazaar (Bzr) — 2005, backed by Canonical (Ubuntu)

Two factors gave Git the lead.

The Linux kernel as flagship project. That the largest open-source project in the world ran on Git was a powerful reference: a tool that held up at Linux's scale would hold up anywhere.

GitHub (2008). GitHub hid Git's harsh edges behind a web UI and added social features (fork, pull request, issues). For individual developers, Git became approachable for the first time. Bitbucket—built around Mercurial—retired Mercurial support on 1 July 2020 and standardised on Git.

Git as Infrastructure

In 2026, Git's dominance is near-total:

• GitHub — over 180 million developers and 630 million repositories, on GitHub's own Octoverse 2025 numbers
• GitLab — the standard for self-hosted enterprise
• Bitbucket — the Atlassian developer ecosystem
• Gitea / Forgejo / Codeberg — open-source GitHub alternatives

Git is no longer merely a VCS:

• CI/CD — a Git push triggers deployment
• GitOps — Kubernetes cluster state is described in a Git repository
• Code review — the pull request is the standard workflow
• AI training data — public GitHub repositories are training corpora for LLMs
• Incident forensics — commit history is evidentiary

Software written in ten days by Linus Torvalds has become, twenty years later, the recording substrate of the world's intellectual production in code.

From SHA-1 to SHA-256

Git's SHA-1 hashing was downgraded to "cryptographically broken" after Google and CWI Amsterdam published the SHAttered collision attack in 2017. Git 2.29 (October 2020) added experimental support for SHA-256 repositories via git init --object-format=sha256. Interoperability between SHA-1 and SHA-256 repositories still does not exist, and the major hosts still do not accept SHA-256 repositories. At twenty, the transition remains Git's unfinished business.

Crucially, the design principle of content addressing is unaffected. Swapping SHA-1 for SHA-256 changes the hash function, not the mental model. The longevity of a design Torvalds wrote in ten days is part of the story.

The Vocabulary That Spread Past Engineers

Git 2005 is a case study in what an experienced designer can produce under extreme constraint and necessity in ten days—with the caveat Torvalds insists on, that the ten days rested on months of prior thinking.

The more important consequence, though, is that distributed version control as an abstraction reshaped collaboration itself. Pull request, code review, branch, merge—this vocabulary, in 2026, has spread beyond engineers to translators, data scientists, and writers.

The goal Torvalds set out on 6 April was not to change the world. It was to assemble a set of tools that would let the kernel keep doing what BitKeeper had allowed—nothing more. The software he wrote in the ten days that followed became the recording medium of nearly every software project on earth.