Two Decades of Git: A Conversation with Linus Torvalds (Category Software)
An interesting account from Linus Torvalds of writing Git’s first version in 10 days, 20 years ago in April 2005. Linux kernel developers had lost access to their preferred tool, BitKeeper. Git was born out of frustration: Linus hated CVS and saw SVN as “the same CVS.” He admits he initially wrote Git for himself, without worrying about other people’s convenience.
He maintained it for only a few months before handing over to Junio Hamano by autumn 2005; Hamano remains the maintainer. Torvalds returned to the Linux kernel, and Git took on a life of its own. After a couple of years, the community began appreciating it, helped by younger developers for whom Git was their first version control system. Instead of struggling with CVS, they happily used Git and wondered why things had ever worked differently. Git took off and almost monopolised version control: according to Linus, roughly 98% of projects now use it. His daughter once told him that her university lab knew him more as Git’s creator than Linux’s 😅.
Git’s key ideas:
1️⃣ Distributed operation There is no inherently central repository: every clone is complete. This is practical, not merely philosophical. Developers can work locally without a central server and publish code wherever they choose; GitHub grew out of that idea. To me, Git is a local-first application by design.
2️⃣ Speed and scalability Git was designed for the huge Linux repository, so operations such as applying patches and merging had to be fast. Linus jokes that applying 100 patches should take seconds: you should not have time for coffee while waiting.
3️⃣ Data reliability Each commit and object has a cryptographic hash, SHA-1. The original emphasis was protection against accidental corruption and mistakes rather than security. Integrity checks throughout distinguished Git from earlier systems; BitKeeper, for example, used weaker CRC/MD5 checks with incomplete coverage.
4️⃣ A simple core A few concepts — objects, indexes and branches — underpin Git. This let the first version be written quickly, and it remains almost fully compatible with today’s version. Complexity was placed above the core, in commands and scripts, or added later.
Inspired by Unix, Linus deliberately avoided copying familiar CVS commands. He used different concepts and names, such as commit-tree and index, provoking arguments on mailing lists. He wanted a radically different tool because the old approaches frustrated him so much.
Git’s history is a great example of a developer solving his own problem and changing an industry. Linus wanted to keep working on the kernel without a dreadful tool, and the result became something developers and team leads cannot imagine working without. Sometimes it is worth building things “properly,” even if the initial product is rough and awkward: with sound foundations, a community can improve it. Open tools can beat closed ones; BitKeeper faded away while Git prevailed.
Torvalds notes that an ecosystem now solves problems he never anticipated, including large-file and monorepository extensions — hello, corporations. Git was not originally designed for those needs, but practice demanded it. His thought on issue trackers is interesting: each hosting provider has its own system, and he would like a common open standard to avoid tying users to one service. Perhaps that is a hint about where the community still has room to innovate 😉.
#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes