Git re-invented the wheel

18 Nov, 2023

Linus Torvalds created the essence of Git over one weekend.

Git went on to become a ubiquitous piece of software.

I wanted to compile parts of the origin story of Git for myself, because I find it a great reminder of how casually taking a first step towards something can lead to something important and complex.

In the early days of Linux, it was common practice to use CVS and SVN ¹ as version control systems for software development. However, these systems, although popular, weren't ideal for handling a large, distributed project like the Linux kernel. So in 2002, BitKeeper ², a proprietary distributed VCS from the company BitMover, was adopted for Linux kernel development.

Torvalds: I really never wanted to do source control management at all and felt that it was just about the least interesting thing in the computing world (with the possible exception of databases ;^), and I hated all SCM’s with a passion. But then BitKeeper came along and really changed the way I viewed source control. BK got most things right and having a local copy of the repository and distributed merging was a big deal. The big thing about distributed source control is that it makes one of the main issues with SCM’s go away – the politics around “who can make changes.” BK showed that you can avoid that by just giving everybody their own source repository. ³

Adopting BitKeeper was a controversial decision from the start ⁴ — it was seen as misaligned with the principles of a flagship free project like Linux. Although Torvalds initially decided to adopt BitKeeper after determining it the most productive tool available, other prominent core developers refused to adopt it.

Larry McVoy (BitMover CEO): Then you go on to complain that the installer doesn't let you see what it does when you can tell it to just drop the tar.gz and the shell script in /tmp so you can see what it does. That wasn't good enough for you, you don't want the installer to be a binary, you mistrust us enough that you think we're going to do some evil thing in the installer. It would take you all of 30 seconds to put strace into a copy of the ftp chroot, stick the installer binary in there, and strace the installer and prove to yourself that it does nothing evil. But that's too much for you.⁵

They were apprehensive that by using BitKeeper, the Linux project might inadvertently grant control of its development processes to BitMover. Relying on a proprietary tool could influence or restrict the way the Linux kernel was developed and managed.

Torvalds: But BK had its own problems, too; there were a few technical choices that caused problems (renames were painful), but the biggest downside was the fact that since it wasn’t open source, there was a lot of people who didn’t want to use it. So while we ended up having several core maintainers use BK – it was free to use for open source projects – it never got ubiquitous. So it helped kernel development, but there were still pain points. That then came to a head when Tridge (Andrew Tridgell) started reverse-engineering the (fairly simply) BK protocol, which was against the usage rules for BK. I spent a few weeks (months? It felt that way) trying to mediate between Tridge and Larry McVoy, but in the end it clearly wasn’t working. So at some point I decided that I can’t continue using BK, but that I really didn’t want to go back to the bad old pre-BK days. Sadly, at the time, while there were some other SCM’s that kind of tried to get the whole distributed thing, none of them did it remotely well. I had performance requirements that were not even remotely satisfied by what was available, and I also worried about integrity of the code and the whole workflow, so I ended up just deciding to write my own.

What is fascinating is how quickly the first version of Git came together.

Torvalds: Heh. You can actually see how it all took shape in the git source code repository, except for the very first day or so. It took about a day to get to be “self-hosting” so that I could start committing things into git using git itself, so the first day or so is hidden, but everything else is there. The work was clearly mostly during the day, but there’s a few midnight entries and a couple of 2 a.m. ones. The most interesting part is how quickly it took shape ; the very first commit in the git tree is not a lot of code, but it already did the basics – enough to commit itself. The trick wasn’t really so much the coding but coming up with how it organizes the data. So I’d like to stress that while it really came together in just about ten days or so (at which point I did my first kernel commit using git), it wasn’t like it was some kind of mad dash of coding. The actual amount of that early code is actually fairly small, it all depended on getting the basic ideas right. And that I had been mulling over for a while before the whole project started. I’d seen the problems others had. I’d seen what I wanted to avoid doing.

Conclusion

It's convenient to not take the path of challenging the status quo. Re-inventing the wheel just to fix a small grievance can seem silly.

After all, software that has a large impact should take months (years?) of research, planning, and development.

But should it, really?

Perhaps creating enough for a first user doesn't have to be a big deal.

Every intimidating project can begin with a simple first commit.

Years after the prevalence of Git, Richard Hipp (creator of SQLite) created Fossil⁶, a VCS designed for the SQLite project.

Notes