Twenty years of Git: Torvalds on the tool that “took over the SCM world”
On April 7, 2005, Linus Torvalds made the first commit to a new version control system, written in just 10 days after the Linux kernel project lost access to its proprietary tool, BitKeeper. Two decades later, Torvalds still uses Git daily—though he admits he never expected it to become what it is.
“Still using it, yes. Maybe not talking about it,” he says. “That has been one of the big surprises—basically how much it took over the whole SCM world.”
Torvalds originally saw Git as a personal solution. “I’ll do something that works for me, and I won’t care about anybody else,” he recalls. In the early months, users complained it was hard and unintuitive. Then, he says, “something happened, like there was a switch that was thrown.”
From BitKeeper to a clean-room design
The path to Git began months before the famous 10-day writing sprint. Torvalds explains that BitKeeper worked well for him—“light years ahead of anything else”—but its commercial, closed-source nature sat uneasily with the kernel community. The situation unraveled when Australian developer Andrew “Tridge” Tridgell reverse-engineered BitKeeper, which violated its license terms. The dispute was irreconcilable, and Torvalds spent roughly four months thinking through what he needed before writing any code.
“How do I do something that does even better than BitKeeper does, but doesn’t do it the way BitKeeper does it?”
The writing itself was a welcome change of pace. “It was fun to do something userspace-y where I had a fairly clear goal,” Torvalds says, noting that user-space programming requires far less care than kernel work. The first version came in at around 10,000 lines and was functional enough for the kernel within about 10 days—though merging took another week to arrive, and the project went through at least one backwards-incompatible object store format change. Today fsck still warns about a few old kernel objects from that early format.
Design philosophy: content hashing over security
Git’s design grew from two core concerns. Performance came first: Torvalds wanted to apply a 50- or 100-patch series in about half a minute. “If things are just instant, some mistake happens, you see the result immediately and you just go on and fix it,” he explains.
The second pillar was integrity. SHA-1 hashes, he says, “were never about the security. It was about finding corruption.” BitKeeper had used CRCs and MD5s, but not universally. Git protected everything with a strong hash from the start—a decision that drove the project’s simplicity at the low level.
Torvalds draws a comparison to Unix. “There’s a fundamental core simplicity to the design and then there’s the complexity of implementation,” he says. Git’s foundational ideas are few; the complications live in the details and interfaces that accumulated as users demanded more.
His regrets are limited. SHA-1 caused “a lot of pointless churn,” he says, with the industry’s worry-driven push for SHA-256 support. He also second-guesses the sorting of index file entries. But these are small details: “All the complexities are elsewhere in the end.”
Early days: plumbing and porcelain
The first week of Git usage involved raw plumbing commands invoked by hand. There was no porcelain layer at all. A commit meant manipulating the index, calling commit-tree, and manually writing the returned SHA into the head file. hash-object was among the earliest binaries, used to verify hashing by hand.
Torvalds scripted shell wrappers around these primitives to make his own life easier, and the early adopters were “pretty hardcore kernel people” already familiar with BitKeeper’s concepts. External patches arrived within days of the public release.
Maintainership lasted only three or four months. Torvalds handed the project to Junio Hamano in August 2005, judging him by taste—visible in patches and in how a person reacts to others’ code. “I was pretty good at picking up who has got the good taste to be a good maintainer,” he says. Hamano’s longevity has proven equally vital. Torvalds notes wryly that his daughter’s university computer science lab knows him better for Git than for Linux.
Why Git scales from class projects to the kernel
Git’s distributed model—where every repository is equal and copying is trivial—made hosting services like GitHub a natural consequence rather than a technical challenge. There is no special repository, no painful migration. git init is the entire setup story for a new project, and growth to collaboration requires nothing more than a push.
“I didn’t realize how many other people wanted it, too,” Torvalds says of such low-friction workflows. He acknowledges that GitHub-style hosting has encouraged thousands of throwaway projects and abandoned repositories, but he is uncertain whether Git fundamentally changed software development. “It makes collaboration easier to some degree,” he says, but the big picture remains unclear to him.
Current use and future challenges
Torvalds remains a deliberately casual Git user. His top commands are git merge, git blame, git log, git commit, and git pull. He has gitk as the only wrapper he ever adopted, and a few personal patches in his tree that he uses but rarely posts. “When it came to Git, it was like Git did what I needed within the first year,” he says. “And when it did what I needed, I lost interest.”
He did follow the project’s gradual improvements—smarter merge strategies and the rewriting of scripts in C for speed—but the multi-hash transition struck him as painful and largely unnecessary.
Looking ahead, one long-standing wish is for better bug tracking. Torvalds would like to see issues become “more unified” across hosting sites rather than fragmented, though he understands why each platform keeps its own system: it is a value-add and a way to retain users even when Git makes code portable.
As for challengers—Jujutsu, Pijul, and others—Torvalds has no interest. “Literally, since I came from being completely uninterested in source control, why would I look at alternatives now that I have something that works for me?”
The rise of unusual workloads, like Microsoft’s monorepo approach, exposed scalability limits that Git “was literally not designed to do,” but Torvalds assumes those issues were resolved since complaints have quieted. “When Git is everywhere, you find all these people who do strange things that you would never imagine—that I didn’t imagine and that I consider to be actively wrong,” he says with characteristic bluntness.
He dismisses the notion that he might be due to build the next big thing. Linux and Git both emerged because nothing existing suited his needs. “Me having to come up with a project is actually a failure of the world—and the world just hasn’t failed in the last 20 years for me.”
For the final word on credit, Torvalds is unambiguous: out of Git’s 20 years, he spent four months. “Really, all the credit goes to Junio and all the other people who are involved in Git that have by now done so much more than I ever did.”
