Ask who created Git and most engineers answer in one breath: Linus Torvalds, over a weekend, out of spite at BitKeeper. Two of those three claims are roughly right. The third is the one worth correcting, because it quietly distorts how people think about a tool they run dozens of times a day. Torvalds did write Git’s original object model and its first working git commit in a documented, dated burst of work in April 2005 — but “weekend” undersells the effort, and worse, it erases what happened next. Three and a half months later, on July 27, 2005, Torvalds handed the project to Junio C Hamano. Hamano has maintained it continuously ever since — roughly two decades, against Torvalds’s few months as sole author. Packfiles, the index format’s several revisions, commit-graph, partial clone, protocol v2, and the ongoing SHA-256 work are all Hamano-era engineering, not Torvalds’s. The record is precise enough to check. Here is the actual timeline, the design goals Torvalds stated at the time, and the contested, attributable story of why any of this needed to happen at all.
The Weekend That Wasn’t
Torvalds began writing Git on April 3, 2005. By April 7, Git was tracking its own source — the standard bar for “does a version control system actually work” is that its own authors trust it with the code that builds it, and Git cleared that bar in four days. That speed is real, well documented, and the origin of the weekend shorthand. It is also a category error. Four days gets you self-hosting: a working object store, a way to snapshot a tree, a way to chain commits, enough plumbing to keep developing the tool with itself. It does not get you an efficient wire protocol, a compact on-disk pack format, garbage collection, integrity checking across an untrusted network, or anything resembling the tooling a project the size of the Linux kernel needs to actually live on day to day.
Torvalds’s own words for what existed on day one, from the README committed alongside Git’s first object: “a stupid (but extremely fast) directory content manager,” built on “a content-addressable collection of objects” with “cryptographically strong signatures at all levels” against corruption [1]. That description is accurate and also modest — it’s a description of a well-designed kernel, not a finished car. The myth conflates the speed of the initial construction with the completeness of the result. Those are different claims, and only the first one is true.
Why the Kernel Needed a New Tool At All
The Linux kernel had used BitKeeper, a proprietary distributed version control system from Larry McVoy’s company BitMover, free of charge for kernel development since 2002. In April 2005, BitMover withdrew that free licence, and the immediate trigger was a tool called SourcePuller, released by Andrew Tridgell, which extracted history out of a BitKeeper repository without a BitKeeper client.
What happened next is genuinely contested, and it should be reported that way rather than resolved into a tidy villain story. BitMover’s Larry McVoy said Tridgell’s tool reverse-engineered BitKeeper’s wire protocol in violation of the free licence’s terms. Tridgell disputed that characterization of what he had actually done. Torvalds’s own contemporaneous reaction, posted publicly at the time, was critical of Tridgell’s release. None of the three accounts fully agree with each other, and the contemporaneous coverage — not any one participant’s later retelling — is the right thing to cite [2]. No lawsuit followed; this was a licensing decision, not litigation, and assigning a single villain to it says more about the storyteller than the record.
The durable lesson isn’t about who was right. It’s a governance lesson: a single proprietary vendor’s licensing call became an existential risk to the entire Linux kernel’s development workflow, independent of who is judged correct in hindsight. That’s the condition Torvalds was actually building against in April 2005 — not “I don’t like this tool,” but “our development process cannot depend on one company’s unilateral decision again.”
April 2005, Reconstructed From the Record
The timeline below is reconstructed from Git’s own object history and Torvalds’s mailing-list posts, not from secondhand retellings — the kind of thing worth pinning down precisely, since it’s the part most often garbled in the retelling.
| Date (2005) | Event |
|---|---|
| Early April | BitMover withdraws the free-for-kernel-development BitKeeper licence in use since 2002, after Andrew Tridgell releases SourcePuller |
| April 3 | Torvalds begins writing Git |
| April 6 | Torvalds announces the new tool on the Linux kernel mailing list |
| April 7 | Git begins tracking its own source — the initial-commit README, object e83c5163316f89bfbde7d9ab23ca2e25604af290 [1] |
| April 19 | Matt Mackall independently releases Mercurial 0.1, a separate response to the same licence withdrawal |
| July 27 | Torvalds’s “Meet the new maintainer..” email names Junio C Hamano the maintainer of git.git [3] |
| 2005–present (~20 years) | Hamano maintains continuously — packfiles, the evolving index format, commit-graph, partial clone, protocol v2, and the ongoing SHA-256 transition are all built after this handoff |
Self-hosting by day four is genuinely rare and genuinely fast. But what “self-hosting” looked like on April 7 is instructive on its own: there was barely a porcelain to speak of. Building a commit meant chaining low-level plumbing by hand — hash-object to write a blob, update-index to stage it, write-tree to snapshot the index, commit-tree to wrap it with a parent pointer, update-ref to move the branch pointer [4]. git commit as a single verb came later. On day four, Git was closer to a toolkit than a tool — which turns out to matter for what it became.
Five Design Goals, and Where Each One Lives in the Object Model
Torvalds stated Git’s design goals directly, and they’re worth quoting rather than paraphrasing: “Speed. Simple design. Strong support for non-linear development (thousands of parallel branches). Fully distributed. Able to handle large projects like the Linux kernel efficiently” [5]. Read as a wish list, that’s five separate requirements. Read against the object model that was already taking shape by April 7, it’s mostly one design decision — separating immutable, hash-addressed content from a thin layer of mutable naming — restated five different ways.
| Design goal (Torvalds’s own list) | Mechanism in the object model |
|---|---|
| Speed | Every commit is a stored snapshot, not a diff to replay; branch creation is a single small ref file write, independent of repository history size |
| Simple design | Four object types — blob, tree, commit, tag — share one on-disk header format (<type> <size>\0 plus zlib compression); git commit itself decomposes into five orthogonal plumbing primitives, not one monolith |
| Strong support for non-linear development | Refs are cheap, independent pointers into one shared object graph; because each commit records its parent’s hash at creation time, a common ancestor between any two branches is computable automatically, not maintained separately |
| Fully distributed | Every clone holds the complete object store and full history; nothing in the data model designates a privileged “central” repository — only convention does |
| Able to handle large projects like the Linux kernel efficiently | Content addressing deduplicates identical content across the entire history for free, since identical bytes always hash to the same object; packfiles and delta compression, engineered later, shrink the transfer and storage footprint of that same snapshot model |
That last row is the one worth sitting with. Deduplication and cheap branching are not features bolted onto Git — they are what a content-addressed object store gives you automatically, once parentage and naming are pulled apart [6]. Non-linear development specifically depends on that graph structure: a merge algorithm is only as good as its notion of a common ancestor, and Git gets that notion for close to free because parent pointers are baked into every commit at creation time rather than tracked out of band [7]. Readers who want the general version of that idea — a directed graph as the substrate a whole class of algorithms falls out of, not just Git’s — will recognize it as the same shape problem that shows up across graph theory generally.
“Meet the New Maintainer..”: July 27, 2005
Three and a half months after the first commit, Torvalds posted an email to the git mailing list with the subject “Meet the new maintainer..” The kernel.org project-owner field, he wrote, now “says ‘Junio C Hamano’ instead” of his own name, and he called Hamano “the obvious choice” [3]. That’s the entire handoff, in Torvalds’s own framing: not a retirement, not a crisis, a straightforward transfer of stewardship to the person who had earned it.
Torvalds didn’t leave software development — he went back to maintaining the Linux kernel, using the tool he had just built for exactly that purpose. What changed was who owned Git’s roadmap, its release cadence, and every design decision from that point forward. Everything discussed in the rest of this article — the parts of Git that make it usable at the scale it’s actually used at today — happened on Hamano’s watch, not Torvalds’s.
Twenty Years of Junio Hamano: The Part the Myth Skips
This is the half of the story the “weekend project” framing erases entirely. Since July 2005, Hamano has maintained Git continuously — through the engineering that turned a fast four-day object store into the tool that runs the Linux kernel, GitHub, GitLab, and most of the software industry’s history. A representative, dated sample:
- The evolving pack format and index format. The binary
.git/index— stat-cache fields, the merge-conflict staging mechanism, the pack format that compresses loose objects into delta chains for storage and transfer — went through multiple revisions well after 2005, none of it present in the April 7 snapshot. ort, a from-scratch merge-strategy rewrite. Elijah Newren’sortstrategy shipped opt-in in Git 2.33 (August 2021), became the default in Git 2.34 (November 2021), and fully absorbed the oldrecursivestrategy’s name in Git 2.50 (July 2025) — sixteen releases and roughly two and a half years of deliberate, overlapping migration under Hamano’s release process, not a weekend’s work by anyone [8].- Commit-graph, partial clone, and protocol v2. All three are Hamano-era additions aimed at the exact problem Torvalds’s fifth design goal names — handling projects at Linux-kernel scale — solved with mechanisms that didn’t exist in 2005 at all.
- SHA-256 repository support. Git has offered SHA-256 repositories, with a documented SHA-1-to-SHA-256 translation table, since version 2.29; the feature was declared non-experimental in 2.42, and limited interoperability arrived in 2.45. SHA-1 remains the default, and full protocol interoperability between SHA-1 and SHA-256 repositories is still incomplete as of Git’s own design documentation [9]. It is accurate to say Git has been building toward a hash transition for years; it is not accurate to say Git has migrated to SHA-256.
Git is also a member project of the Software Freedom Conservancy, which it joined in December 2010, with Hamano sitting on the project’s Leadership Committee [10] — institutional evidence of two decades of stewardship, not just a résumé line. None of this is listed to diminish April 2005. It’s listed because the myth needs both halves to be wrong to survive: it has to forget that a tool needs decades of unglamorous engineering to become the version everyone actually runs, and it has to forget the specific, named person who did most of that engineering. If you want to see the receipts yourself rather than take a summary’s word for it, reading the actual commit log — starting from object e83c5163 and walking forward — is a more convincing argument than any article, including this one.
Mercurial’s Parallel Origin
Git was not the only serious answer to BitMover’s licence withdrawal. On April 19, 2005 — twelve days after Git began tracking its own source, and independently of it — Matt Mackall released Mercurial 0.1, a distributed version control system built as its own response to the same event [11]. Mercurial and Git were not competitors racing on the same starting line so much as two separate engineering teams recognizing the same problem at the same moment and building two different answers to it. Both tools shipped, both survive in production use today, and both are proof that the pressure behind Git’s creation was structural — an entire community suddenly needing a distributed alternative — rather than a single person’s isolated inspiration. That context matters for the myth too: “Torvalds invented distributed version control in a weekend” was never true either way, since Mercurial’s team was solving the identical problem in parallel, in public, in the same month.
The Architecture Lesson Underneath the History
The reason a two-week initial build could be extended for twenty years without a ground-up rewrite is itself the transferable lesson. Torvalds’s first real decision — separate immutable, hash-addressed content from a thin, mutable layer of naming (refs) — left room for nearly everything that came later to be added underneath or beside that model instead of requiring it to be replaced. Packfiles compress the object store without changing what an object is. Commit-graph adds a faster index over the same DAG without changing what a commit means. Protocol v2 changes what gets negotiated over the wire without touching the object format at all. A data model that a maintainer can extend for two decades without breaking it is a rarer achievement than a data model that ships fast, and it’s the actual, checkable reason Git is still the tool in twenty years’ use rather than one more abandoned 2005 project.
It’s also worth being precise about what that data model does and doesn’t promise. Torvalds’s own README described “cryptographically strong signatures at all levels” against corruption — true, and worth taking literally rather than loosely: Git’s hashes are excellent at detecting accidental or malicious tampering after the fact. They were never a claim about who authored anything; that’s a separate, later problem solved by signing, not by hashing. A maintainer model built on that same distinction — a fast, mechanical layer that can be trusted for one narrow guarantee, plus a slower, human layer of review and accountability for everything the mechanical layer can’t promise — is a pattern worth recognizing anywhere trust decisions get made under automation, including in the current debate over how much human review AI-generated changes still need. Git’s own history answers a version of that question already: the object model handles integrity; a single accountable maintainer, for two decades, handled everything else. Readers building or reasoning about any system with its own extend-without-rewrite loop will recognize the shape. It’s the same argument this site makes about why another apparently “sudden” system is really decades of incremental engineering wearing a simple-looking front end.
❓ Frequently Asked Questions
Who created Git? Linus Torvalds wrote Git’s original object model and implementation, beginning April 3, 2005, with Git tracking its own source by April 7, 2005. Junio C Hamano has maintained the project continuously since Torvalds named him maintainer on July 27, 2005 — roughly two decades, against Torvalds’s few months as sole author.
Did Linus Torvalds really write Git in a single weekend? No. Development began April 3, 2005, and self-hosting was reached April 7 — a fast four days, not a weekend, and self-hosting is a much lower bar than the feature-complete tool in use today. Most of what makes modern Git usable at scale — packfiles, commit-graph, partial clone, protocol v2, SHA-256 support — was built after Torvalds handed the project off in July 2005.
What exactly happened with BitKeeper in April 2005? BitMover withdrew the free licence the Linux kernel had used for BitKeeper since 2002, after Andrew Tridgell released a tool called SourcePuller. The characterization of that event is contested: BitMover’s Larry McVoy said Tridgell had reverse-engineered BitKeeper’s protocol in violation of the free licence; Tridgell disputed that characterization; Torvalds’s contemporaneous public reaction was critical of Tridgell. No lawsuit followed, and no single account should be treated as the settled version.
Who is Junio Hamano, and why is he called Git’s maintainer rather than its creator? Hamano did not write Git’s original code — Torvalds did. But Torvalds named Hamano maintainer on July 27, 2005, and Hamano has run every subsequent release, design decision, and major engineering effort since, for roughly twenty years. “Creator” and “maintainer” describe two different, non-overlapping contributions, and Git’s post-2005 engineering belongs to the second one.
Did Mercurial and Git start at the same time? Nearly. Matt Mackall released Mercurial 0.1 on April 19, 2005, an independent response to the same BitKeeper licence withdrawal, twelve days after Git began tracking its own source. Neither project was built in reaction to the other.
Has Git changed much since Torvalds handed it off in 2005? Substantially. The pack and index formats, commit-graph, partial clone, protocol v2, the ort merge strategy (2021–2025), and SHA-256 repository support (in progress since 2020, still not the default) were all engineered after the July 2005 handoff, under Hamano’s continuous maintenance.
Sources: [1] git.git initial commit, object e83c5163316f89bfbde7d9ab23ca2e25604af290 — https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290 · [2] The Register, “Tridgell drops Bitkeeper bombshell,” April 22, 2005 — https://www.theregister.com/2005/04/22/tridgell_releases_sourcepuller/ · [3] Linus Torvalds, “Meet the new maintainer..,” git mailing list, July 27, 2005 — https://marc.info/?l=git&m=112243466603239 · [4] Pro Git, “Git Internals: Git Objects” — https://git-scm.com/book/en/v2/Git-Internals-Git-Objects · [5] Pro Git, “A Short History of Git” — https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git · [6] Linus Torvalds, Google Tech Talk transcript, May 2007 — https://git.wiki.kernel.org/index.php/LinusTalk200705Transcript · [7] Git documentation, git-merge-base — https://git-scm.com/docs/git-merge-base · [8] GitHub Blog, “Highlights from Git 2.34” — https://github.blog/open-source/git/highlights-from-git-2-34/ · [9] Git documentation, hash-function-transition — https://git-scm.com/docs/hash-function-transition · [10] Git and the Software Freedom Conservancy — https://git-scm.com/sfc/ · [11] Architecture of Open Source Applications, Vol. 2, “Git” (Susan Potter) — https://aosabook.org/en/v2/git.html
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.
Pro Git
Scott Chacon & Ben Straub · 2nd ed., Apress · Book · ~$35 on Amazon
The canonical Git book, and the primary source for most of the design-goals quotes in this article — chapter 10, “Git Internals,” is the closest thing to an official account of the object model. It’s also free: the full text is published online at git-scm.com/book under a CC BY-NC-SA 3.0 licence, so read it there first and buy the print copy only if you want it on a shelf.
The Cathedral and the Bazaar
Eric S. Raymond · O’Reilly · Book · ~$25 on Amazon
Not a Git book — a governance book, and the right lens for the BitKeeper story in this article. Raymond’s essay on open-source development models predates Git by six years, but it’s the clearest available account of why a project’s governance structure, not just its code, determines whether a single vendor’s decision can hold an entire community hostage — exactly the condition Torvalds built Git to escape. The title essay is free at catb.org/~esr/writings/cathedral-bazaar under the Open Publication License; the print edition adds the rest of the collected essays.
Version Control with Git
Prem Kumar Ponuthorai & Jon Loeliger · 3rd ed., O’Reilly · Book · ~$55 on Amazon
Once you know the history, this is the practical companion for putting the object model to work — a full treatment of Git’s commands and workflows written by engineers who clearly understand the plumbing underneath them, not just the porcelain on top.
Building Git
James Coglan · Ebook only, no Amazon listing
Coglan’s book walks through implementing a working subset of Git from scratch in Ruby — the single best way to internalize why the object model shapes everything downstream from it. It has no print edition and no Amazon listing; it’s sold directly by the author as PDF/ePub/Kindle at shop.jcoglan.com/building-git. Linked here for reference, not as an affiliate purchase — no commission applies to this one.