AI Grew Up on Git, Part 1: Trust No One, Hash Everything
How a licensing betrayal taught a version control system to trust nobody, and why every open model, framework, and reproducible paper in AI inherited that suspicion
This is AI Grew Up on Git, a series on the infrastructure that raised artificial intelligence and what AI is now doing to it. Across eight parts it traces how Git and GitHub set the speed and shape of modern AI, and teaches you to read and use Git along the way.
For the first decade of its life, the largest collaborative software project in the world ran on email.
Linux kernel contributors wrote their changes, formatted them as patches, and mailed them to a list. Linus Torvalds read the list. When a patch looked right, he applied it to his tree by hand. This worked, in the way that a single overworked person is always the thing that works, right up until it doesn’t. By the late 1990s the kernel was too large for one man’s inbox, and the patches were arriving faster than any human could merge them. The project needed a tool. It found one that would nearly destroy it.
In 2002 the kernel adopted BitKeeper, a distributed version control system built by Larry McVoy’s company, BitMover. BitKeeper was good. It was, by most accounts of the people who used it, considerably better than anything else available, and McVoy, a real believer in open source, made it free for open-source projects to use. The arrangement had one structural flaw, and the flaw was not in the software. It was in the sentence “free for open-source projects to use, from a company whose product is not open source.” That sentence held a contradiction, and the whole arrangement depended on no one forcing it.
For three years it held anyway. Then it didn’t.
The arrangement that could not hold
The person who pulled the wall down was not trying to.
Andrew Tridgell, a developer at the Open Source Development Labs, wanted something ordinary: the ability to see the metadata in a BitKeeper repository, the record of who changed what and when, the differences between one version and the next. Being able to look at that history is a basic feature of every version control system ever written. It was also, for anyone without a paid commercial license, exactly the thing BitKeeper would not let you do. So Tridgell built a small free client that could read it.
McVoy called this reverse engineering. In April 2005, BitMover announced it would stop giving BitKeeper away, and named Tridgell’s work as the reason. The company went further and refused commercial licenses to anyone employed by OSDL, a group that included Andrew Morton and Torvalds himself. The tool the kernel had come to depend on was being pulled out from under it, and the man who maintained the kernel was among the people locked out.
What happened next is one of the stranger episodes in open-source history, because the two most famous programmers in the room ended up on opposite sides of it. Torvalds, whose kernel was the collateral damage, publicly sided with McVoy against Tridgell. A trade-press headline from that April put it with unusual bluntness: “Torvalds knifes Tridgell.” One open-source titan had just knifed another in defense of a proprietary product, on behalf of the very company that had just locked him and his fellow OSDL developers out. The politics were a knot. Nobody looked good. Everybody was, in some defensible sense, right.
Tridgell answered from a stage.
Days after Git’s earliest code already existed, at the linux.conf.au conference in Canberra, Tridgell gave a keynote and, partway through, offered to demonstrate the terrible act of reverse engineering he stood accused of. He did not do it himself. He asked the audience to call out the commands he should type. Open a telnet connection. Connect to port 5000 on the BitKeeper server. Type help. The server printed its own list of commands to the screen, a menu of exactly how to talk to it, and a room full of people had just co-authored the “hack” out loud in about two minutes. There was no cunning. There was a network port and a help command, and the entire ferocious dispute about Tridgell’s methods dissolved into laughter, because whatever he had done, it was the sort of thing a room of strangers could reconstruct in the time it takes to find your seat.
The demonstration is remembered as comedy. Underneath it sits the whole problem the next tool would have to solve. BitKeeper’s protection was a locked door in a building with no walls. Its authority over the kernel’s history rested on a company’s willingness to keep a promise, and a promise, it turned out, was revocable at a company’s convenience. The kernel had trusted an institution, and the institution had every legal right to change its mind.
Four months of not writing code
The story you have probably heard is that Linus Torvalds wrote Git in ten days.
The story is true. It is also the least interesting true thing about it, because it hides the four months that explain the software. In interviews given two decades later, Torvalds is precise about the timeline, and the precision matters. The ten days of coding were real. They rode on top of roughly four months of thinking that began, by his account, in November or December of 2004, well before the BitKeeper license died. He was not caught flat-footed by the April crisis. He had been quietly turning the problem over since the previous autumn.
And the thing he spent those months on was not code. It was a constraint.
Torvalds understood the trap he was in. He and BitKeeper had a history. He knew the tool intimately, admired parts of it, and was about to build a replacement. If that replacement resembled BitKeeper too closely, McVoy would have a case, and Torvalds refused to hand him one. So before writing a line, he spent months deciding how to build something that owed BitKeeper nothing, something whose design could not be described as derived. The four months were not slow. They were the opposite of the ten days: the ten days were fast because the four months had been thorough.
He set himself criteria that read, in retrospect, like a specification for the future. The system had to be fully distributed, with no central server anyone could switch off. It had to be fast, fast enough to make version control feel free rather than expensive. And it had to be secure in a specific and unusual sense: it had to guarantee, cryptographically, that the history it stored could not be corrupted, whether by accident or by malice, whether by an outsider or by the machine holding the repository. Those three demands, taken together, ruled out every version control system then in existence. None of them could do all three. So he wrote one that could.
This is why the ten-day story is the wrong story to keep. The ten days tell you Torvalds is fast, which everyone already knew. The four months tell you what Git is, which is the more useful thing. Git is not a tool that was thrown together in a panic. It is a tool designed, slowly and deliberately, around a wound. The wound was trust.
A theory of distrust, written in C
To understand what Torvalds built, start with what everyone else had built, because Git’s central idea is a refusal of it.
Every version control system before Git thought in terms of changes. You have a file. You edit it. The system records the difference between the old version and the new one, a compact little record of what changed, and it stacks these differences up over time. To reconstruct any past version, it takes the original and replays the differences forward. This is efficient and intuitive and it is how nearly everyone had always done it. It also quietly assumes that the pile of differences, and the server holding them, can be trusted to be honest.
Git thinks in snapshots instead. When you save your work in Git, it does not store the difference from last time. It stores the entire state of your project at that moment, a complete photograph of every file, and it gives that photograph a name. The name is where the whole design turns.
Git names each snapshot by computing a hash of its contents. A hash is a mathematical function that reads a pile of data and produces a short fixed-length string, a fingerprint, with one essential property: change the data by even a single character and the fingerprint changes completely and unpredictably. The name of a Git snapshot is therefore not a label attached to the content. It is computed from the content. It is a name that cannot lie. If someone alters so much as one byte inside a snapshot, its fingerprint no longer matches, and Git notices instantly, because the name it expects and the name the content now produces have stopped agreeing.
Now chain these together. Each Git snapshot, when it is saved, records the fingerprint of the snapshot that came before it. That earlier snapshot recorded the one before that, and so on back to the very first. The result is a structure where every entry is sealed by its own contents and also seals its parent’s, an unbroken cryptographic chain running the entire length of the project’s history. To tamper with any point in the past, you would have to change that snapshot, which changes its fingerprint, which breaks the link in every snapshot that came after it, all the way to the present. The history does not merely record what happened. It makes any lie about what happened mathematically visible.
Notice what this removes. There is no central server that has to be trusted, because there is no central server at all. When you copy a Git repository, you do not check out a slice of it from an authoritative host. You receive the entire history, the whole chain, a full and equal copy that lives on your own machine and stands on its own. Every clone is complete. Every clone can verify itself. Authority does not live in a place; it lives in the arithmetic, and the arithmetic is on everyone’s laptop at once.
Read that against April 2005 and the design stops looking like engineering and starts looking like an argument. BitKeeper’s history had lived on terms a company controlled, and the company had revoked them. Git’s history lives on terms no one controls, because it is secured by a mathematical fact rather than a commercial promise. You cannot revoke what everyone already fully possesses, and you cannot secretly rewrite what every copy can independently check. Torvalds had been burned by a revocable arrangement, and he responded by building one that could not be revoked. The distrust was the point. He designed a system that assumes the worst about every server, every company, and every collaborator, and is therefore safe in a world where the worst sometimes happens.
Ten days, measured
With the constraint settled, the coding was almost anticlimactic.
Development began on April 3, 2005. Torvalds announced the project to the kernel community on April 6. On April 7, one day later, Git could already manage its own source code, and the first commit ever recorded in Git was made using Git itself, the tool booting up its own history the moment it became able to. The commit is still there. Its message reads: “Initial revision of ‘git’, the information manager from hell.” He was not, on the evidence, feeling reverent about it.
From there the milestones fall like dominoes. The first merge of separate branches of development landed on April 18. On April 29, three weeks into the tool’s existence, Torvalds benchmarked it recording patches to the kernel tree at a rate of 6.7 patches per second, which for a version control system in 2005 was not merely fast but absurd. On June 16, barely two months after the first commit, Git managed the release of Linux kernel 2.6.12. The emergency tool had become the real tool, and it had done so in the span of a single spring.
The name deserves its own moment, because it tells you something about the culture Git was born into. “Git” is British slang for an unpleasant, contemptible person. Torvalds chose it on purpose, and when asked why, offered a whole menu of readings rather than settle on one. The tool’s own early documentation lays them out with a shrug: the name is a random three-letter combination that is easy to pronounce and not already taken by some Unix command, or it is a mispronunciation of “get,” or it is simply an insult, stupid and contemptible and simple, take your pick from the dictionary of slang. The most widely repeated version of the joke has Torvalds explaining that he names all his projects after himself, first Linux, now Git. The line circulates in more than one wording and you should trust the sentiment more than any exact transcription of it. Either way, the world’s most important piece of collaborative software is named after a jerk, by a man cheerfully volunteering himself as the referent.
The handover, and what was actually built
About a week after that first commit, a new name started appearing in Git’s own history: Junio Hamano.
Hamano was not the founder and never claimed to be. He was the contributor who kept showing up, who by the time of the 0.99 release had accumulated hundreds of commits, who treated the raw and jagged early tool as something worth polishing into an instrument other people could hold. On July 26, 2005, a little over three months after starting Git, Torvalds handed him maintainership of the project. Two decades later, Hamano still holds it. Git had two acts of creation, then: the founder who gave it its theory of distrust in ten days, and the maintainer who gave it its longevity across twenty years, and the second is why the first still runs the world.
Torvalds, for his part, has always been clear that he did not build Git out of any love for version control. He built it because the kernel needed one and the old one was gone, and he intended from the start to hand it off to someone who wanted the job. He wrote a tool to get himself unstuck, and then he got himself unstuck, and the tool went on to outgrow every purpose he had for it. That is the honest shape of the story. It was a rescue, not a crusade, and it produced the foundation for a global commons almost by accident.
Because what Torvalds had built, underneath the snapshots and the hashes and the ten-day sprint, was trust infrastructure. He had built a way for enormous numbers of strangers to share a single history that none of them could quietly corrupt and no company could take away. That is a strange and powerful thing to have lying around, and once it existed, people put more and more on top of it than the kernel. Within a few years an entire culture of open collaboration would move onto Git’s foundation, and eventually so would nearly all of open artificial intelligence: the frameworks models are built with, the model weights themselves, the papers whose results you can rerun. The open AI ecosystem sits on machinery designed in a Finnish programmer’s head over the winter of 2004, machinery built on the assumption that the collaborators cannot be trusted and the history must prove itself.
That assumption has held for twenty years. It was built for a world of human collaborators who might be careless or hostile. What happens to a theory of distrust when the collaborators stop being human at all is the question the rest of this series follows.
The Working Tree
Everything in this part comes down to one habit Git has: it takes named snapshots of your work and chains them into a history you can inspect. Here is that habit at the keyboard.
You start by turning a folder into a repository. This creates the hidden machinery that will store your snapshots.
git init
Now you work, editing files as usual. When you have something worth recording, you do it in two steps. First you choose what goes into the next snapshot. This is called staging.
git add .
Then you take the snapshot. This is a commit, and it is the moment Git computes that content-based fingerprint and seals it into the chain.
git commit -m "Describe what this snapshot contains"
At any point you can ask Git what has changed since your last snapshot, which is what stands between you and committing something by mistake.
git status
You can walk back along the chain of snapshots, newest to oldest, and see the sealed history the previous sections described.
git log
And you can ask Git to show you the actual differences, not because Git stored them, remember, but because it can always compute them by comparing two whole snapshots.
git diff
Six commands. Behind them is the entire idea of the last twenty years: save the whole state, name it by its contents, chain the names, and never trust anyone to tell you the history is intact when you can check it yourself.
commit 1/8
What changed: Version history stopped needing a trusted server; every copy became the proof.
Why: The kernel had trusted a company once, and the license did not survive the trust.
This is Part 1 of AI Grew Up on Git, a series on the infrastructure that raised artificial intelligence and what AI is now doing to it. Part 2 turns to the platform that made Git social, and to the invention that was never part of Git at all: the pull request.