AI Grew Up on Git, Part 2: GitHub Didn’t Invent the Pull Request. It Socialized It.
Git already knew how to move code between strangers. GitHub’s real invention was making strangers want to, and that social layer is where modern AI’s training corpus was waiting.
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.
By 2007, Git had won the argument and lost the room.
The tool Linus Torvalds had built in ten days, the subject of Part 1, was by any technical measure a triumph. It was fast, it was distributed, it secured its own history against tampering, and it had already proven itself on the largest software project on earth. It was also, for most working programmers, close to unusable. Its command line assumed you already thought the way Torvalds thought, in terms of trees and objects and refs, and it punished you when you didn’t. People who had spent a decade comfortable with older tools opened Git, ran three commands, broke something they didn’t understand, and quietly went back to what they knew.
This is the gap the second half of Git’s story grows out of, and the usual account of it runs backward. Git did not fail to solve collaboration. It solved exactly one side of collaboration completely: the maintainer’s side. A person drowning in patches from thousands of contributors now had a fast, trustworthy way to take those patches and merge them. What Git did nothing for was the other side, the newcomer’s side. If you were a stranger with a small improvement to offer, Git gave you no easy way in. You could generate a patch, but then what? Sharing your work meant running your own server, or trading obscure incantations with someone who would agree to pull from you. There was no place code simply lived, in the open, where another person could see it, take it, and hand something back.
Two developers in San Francisco felt this friction acutely, because they were living inside it. Around a 2007 Ruby meetup, Chris Wanstrath and Tom Preston-Werner kept circling the same complaint: Git was a better way to work with other people on code, and there was no easy way to do that with a group. The distributed machine had been built. Nobody had built the front door.
The weekend hack that took three months of Saturdays
The story that gets told is that GitHub was a weekend hack.
It is a good story, and like the ten-day story about Git, it survives because it is cleaner than the truth. Preston-Werner wrote his own account of those months in 2008, and the account is not a weekend. It is a quarter of a year of nights and weekends, layered on top of full-time jobs. He kept building Grit, a Ruby library he was writing to let code read a Git repository, and he designed the interface. Wanstrath built out the Rails application that would become the site. Neither of them was doing this instead of working; they were doing it after working, on the edges of their weeks.
And they met, every Saturday, in person, to decide what the thing would be. The decisions were not all glamorous. One rainy Saturday, by Preston-Werner’s own recollection, the two of them spent a solid two hours arguing about pricing strategy over some of the best Vietnamese egg rolls in the city. That is the real texture of it: not a hackathon montage, but two people in a restaurant on a wet afternoon, deciding how a business none of the world had asked for would eventually charge money. In mid-January of 2008, after three months of this, they opened a private beta and sent invites to their friends. In mid-February, P.J. Hyett joined and made them three. On April 10, 2008, they launched the site publicly, without a single dollar of outside investment and, as Preston-Werner noted with some satisfaction, without inviting TechCrunch. A fourth name, Scott Chacon, is credited among the founders for his Git expertise.
The pattern is the same one Part 1 described. The origin stories the industry keeps are the compressed ones. Torvalds wrote Git in ten days, except the ten days rode on four months of design. GitHub was a weekend hack, except the weekend was a quarter of Saturdays and a pricing argument over egg rolls. The myth keeps the sprint and deletes the deliberation, every time, because the sprint is what sounds like magic.
The clearest measure of how much Preston-Werner believed in the thing arrived after launch, not before. On July 1, 2008, the company he worked for, a natural-language search startup called Powerset, was acquired by Microsoft for around a hundred million dollars. As part of the deal, Preston-Werner was offered a retention package to stay: three hundred thousand dollars over three years, plus stock. He was twenty-nine, carrying debt, and GitHub had been a public website for three months and had earned him nothing. He turned the money down and quit to work full-time on the free thing he had built on Saturdays. Ten years later, Microsoft would buy that free thing for seven and a half billion dollars, but that is a later part of this series, and on the day he said no, it was simply a bet against a sure salary.
The thing GitHub did not invent, and the thing it did
The pull request has an origin story, and the popular version credits the wrong people with the wrong invention.
The idea of requesting a pull was not new, and it was not GitHub’s. It was not even, strictly, an idea GitHub improved. Long before the site existed, kernel maintainers using BitKeeper would email Torvalds asking him to pull their changes. A real message from 2003 reads, in essence, “Linus, please do a bk pull from this address to get my latest changes,” followed by a summary of what those changes were. When Git replaced BitKeeper, this courtesy came along. In July 2005, a contributor named Ryan Anderson, not Torvalds, wrote a small command called git request-pull that automated the summary: point it at a repository and it generates a tidy message a maintainer can read and act on. The mechanism of asking someone to pull your code was, in other words, roughly as old as Git itself, and older.
So when GitHub added a “pull request” feature in February of 2008, it did not invent the pull request. What it shipped, at first, was thin almost to the point of anticlimax. The earliest version was close to a graphical wrapper around git request-pull. You clicked a button, and GitHub sent a notification to another user. The notification named the repository and the specific commit to pull from, offered a link to view the commits involved, and gave you a little box for a short message. That was it. The recipient, having received this polite web notification, then went to their terminal and pulled the commits by hand, exactly as they would have from an email. It was a glorified email with a link, and it stayed close to that for roughly two years.
If the story ended there, GitHub’s claim to an invention would be thin. It doesn’t end there, and the thing GitHub built next took time to arrive. In August 2010, GitHub rebuilt the feature into what it called Pull Requests 2.0, and this is the moment the pull request became the thing we now mean by the words. The ephemeral notification, which had existed only briefly and only in someone’s inbox, became a permanent, public page. It carried a discussion. People could argue about the code on it, in the open, and the argument was preserved. Inline comments on specific lines of a diff arrived in February 2011. The button that finally let you merge a pull request without dropping to a terminal appeared in April 2011.
Now the distinction is clean. The plumbing, the moving of commits from one place to another, was never GitHub’s invention and never Git’s weakness. What was never part of Git, and never part of git request-pull, was the pull request as a social object: a durable, public page attached to a copy of a project, where a specific proposed change becomes a conversation that strangers can join, review, and settle. Git moved code between machines. GitHub moved the conversation about code onto a page anyone could open. Those are different acts, and only the second one was new.
Gravity
The other half of GitHub’s social invention was a button that changed what it meant to copy someone’s work.
Before GitHub, copying an entire project’s codebase to your own space carried a whiff of divergence, even hostility. To “fork” a project in the older open-source sense was a semi-hostile act, a declaration that you were splitting off to go your own way. GitHub took the same word and drained the hostility out of it. On GitHub, you forked a project not to leave it but to contribute to it. The fork was your personal copy, the place you made your change safely, and it was the necessary first step toward a pull request that would hand the change back. Forking stopped meaning “I am leaving” and started meaning “I am about to help.” That is a change in social meaning, accomplished entirely through interface, and it did more to open source than any feature Git shipped.
The effect on growth was immediate and public. Speaking to a developer audience in February 2009, less than a year after launch, Preston-Werner reported that GitHub was hosting more than forty-six thousand public repositories, and that roughly seventeen thousand of them had appeared in the previous month alone. By that July, the site had passed a hundred thousand users. The curve was not linear, and everyone watching could see it.
The mechanism underneath the curve is simple, and it is the whole point. The pull request lowered the cost of accepting code from a stranger to almost nothing. Recall the problem from Part 1: open source had always been throttled by exactly this cost, the difficulty and risk of taking work from people you did not know and could not vouch for. Git had made it technically safe to accept a stranger’s history without trusting them, because the history proved itself. GitHub now made it socially easy, a reviewable page and, eventually, a single button. Safe plus easy is a different world from safe alone.
And once contributing was that easy, gravity took over. The programmers were on GitHub, which meant the contributions were on GitHub, which meant that a project hosted anywhere else was a project cut off from the largest pool of people who might improve it. Projects that had lived for years on their own servers began mirroring themselves to GitHub, not because their maintainers loved the company but because that was where the help was. The center of open-source collaboration migrated to a single website, one convenience at a time, until “open source” and “on GitHub” were nearly the same sentence.
The corpus nobody was planning
GitHub set out to make collaboration pleasant. It succeeded, and in succeeding it built something nobody in that Vietnamese restaurant was designing.
Pleasant collaboration, at the scale GitHub reached, is also a record. Every fork is a labeled copy of a project with a known parent. Every pull request is a proposed change paired with a discussion of why it was made, whether it was accepted, and how it was revised. Every review comment is a human being explaining, in context, what is wrong with a specific line of code and how to fix it. None of this was created to be data. All of it is, in the strict sense, some of the richest structured signal about how humans actually write and correct software that has ever existed in one place: paired problems and solutions, proposals and critiques, all human-generated, all linked, all sitting on one platform.
The thing that made GitHub valuable to a developer in 2009, the fact that it captured not just code but the whole conversation around code, is the same thing that made it priceless to a language model a decade later. A model that learns to write code learns best from exactly this: not just finished programs, but the arguments about them, the mistakes and the corrections, the before and the after of a merged change. GitHub had spent ten years accumulating that, purely as a byproduct of being a good place to work.
This is the throughline the series is tracing. Part 1 built the distrust machinery, a way for strangers to share a history none of them could corrupt. Part 2 built the social layer that filled that machinery with people, and therefore, without anyone intending it, with data. The infrastructure that would later raise artificial intelligence was assembled for entirely human reasons, one convenience at a time, by people optimizing for a pleasant Saturday’s work and a business that could pay its founders. No model was in view. The corpus was a side effect of hospitality. What a company would eventually pay billions to own, and what a model would eventually train on, was built by three people trying to make Git easy enough to use.
The Working Tree
Part 1 gave you the local habit: snapshots, named and chained, on your own machine. This part is about moving that history between machines and wrapping it so strangers can contribute. Here are the commands underneath everything above.
You start by copying an entire project, its full history included, from somewhere else. This is clone, and note what it gives you: not a slice, but the whole self-verifying history from Part 1.
git clone https://github.com/someone/project.git
A remote is just a named location where another copy of the history lives, usually the one you cloned from, which Git conventionally calls origin.
git remote -v
You move commits between copies with push and pull. Push sends your local commits to a remote; pull brings a remote’s commits into your local copy and merges them in.
git push origin main
git pull origin main
When you want to see what a remote has without merging it into your work yet, you fetch. This looks, without changing anything you’re holding.
git fetch origin
The social layer sits on top of these. On GitHub, you fork a project, which is a server-side clone into your own account. You make your change on a branch, push it to your fork, and open a pull request: the durable, public page this part described, where your proposed change becomes a conversation before anyone merges it. The plumbing is all Git. The page is all GitHub.
commit 2/8
What changed: Contributing to someone else's code stopped requiring their permission to start, only their approval to finish.
Why: GitHub wrapped Git's pulling in a social object, and the cost of a stranger's first contribution fell to one button.
This is Part 2 of AI Grew Up on Git, a series on the infrastructure that raised artificial intelligence and what AI is now doing to it. Part 3 turns to a company that rebuilt GitHub’s entire playbook for a kind of file Git was never able to hold: the model weight.