Celebrating 20 Years of Git: 20 Interesting Facts From its Creator

To celebrate this milestone, Linus was recently featured on GitHub's official YouTube channel (you can watch the video below or read the full interview with Taylor Blau). We thought this would be a great opportunity to present this conversation to the Tower community.

In this insightful conversation, Torvalds reflects on:

• the origins of his groundbreaking project
• his initial expectations (or lack thereof)
• the key decisions that shaped Git into the ubiquitous version control system we know today.

Join us as we celebrate two decades of Git by exploring these engaging tidbits straight from the mind of its legendary creator!

Here are 20 interesting (and fun) facts about the early days of Git.

The original transcript has been lightly edited for the purpose of this blog post.

20 Facts About Git

1. Git was born out of necessity to solve a specific problem.

Linus Torvalds didn't embark on creating Git with the goal of global domination in mind. His primary motivation was to solve his own immediate problem: the need for a better version control system for the Linux kernel development. He had a strong negative opinion of existing systems like CVS and even felt his initial, raw version of Git was already an improvement.

"I saw it as a solution to my problems, and I obviously thought it was superior. Even literally 20 years ago to the day, I thought that first version, which was pretty raw — to be honest, even that version was superior to CVS."

2. The initial version of Git was developed in approximately 10 days.

While the groundwork and conceptualization took longer, the intensive coding period to get a working version of Git for kernel use was remarkably short, highlighting Linus's deep understanding of the requirements.

"It was actually fewer than — well, it was about 10 days until I could use it for the kernel, yes. But to be fair, the whole process started like December or November the year before, so 2004."

3. The reverse engineering of BitKeeper ultimately led to Linus creating Git.

The commercial nature of BitKeeper and the restrictions it placed on reverse engineering caused friction within the open-source kernel community. When this led to the loss of free BitKeeper usage, Linus felt compelled to create an open-source alternative.

"What did come up was that Tridge in Australia basically reverse engineered BitKeeper, which wasn’t that hard because BitKeeper internally was basically a good wrapper around SCCS, which goes back to the 60s. SCCS is almost worse than CVS. But that was explicitly against the license rules for BitKeeper. BitKeeper was like, you can use this for open source, but you can’t reverse engineer it. And you can’t try to clone BitKeeper. And that made for huge issues."

4. Linus spent about four months mentally planning the design of Git before writing the initial code.

The ten-day coding sprint was preceded by a significant period of thinking through the problems he wanted to solve and how Git could improve upon existing systems without infringing on BitKeeper's licensing.

"So by the time I started writing Git, I had actually been thinking about the issue for four months and thinking about what worked for me and thinking about “How do I do something that does even better than BitKeeper does but doesn’t do it the way BitKeeper does it?” I did not want to be in the situation where Larry would say, “Hey, you did the one thing you were not supposed to do.” So yes, the writing part was maybe 10 days until I started using Git for the kernel, but there was a lot of mental going over what the ideas should be."

5. For Linus, programming Git in userspace felt easier than dealing with the complexities of kernel development.

Working on a userspace tool allowed Linus to focus on higher-level logic without the low-level memory management and hardware considerations inherent in kernel development.

"And it was kind of interesting because it was — one of my reactions was how much easier it is to do programming in the userspace. There’s so much less you need to care about. You don’t need to worry about memory allocations. You don’t need to worry about a lot of things. And debugging is so much easier when you have all this infrastructure that you’re writing when you’re doing a kernel. So it was actually somewhat — I mean, I wouldn’t say relaxing, but it was fun to do something userspace-y where I had a fairly clear goal of what I wanted. I mean, a clear goal in the sense I knew the direction. I didn’t know the details."

6. A primary design goal for Git was performance, particularly in efficiently applying large series of patches.

Linus wanted Git to handle the numerous patches involved in kernel development quickly, aiming for operations that wouldn't even require a coffee break.

"But for me, one of the goals was that I could apply a patch series in basically half a minute, even when it was like 50, 100 patches. It’s one of those things where if things are just instant, some mistake happens, you see the result immediately and you just go on and you fix it. And some of the other projects I had been looking at took like half a minute per patch, which was not acceptable to me. And that was because the kernel is a very large project and a lot of these SCMs were not designed to be scalable."

7. The use of SHA-1 hashes in Git was primarily for detecting data corruption and ensuring stability, rather than for security purposes.

While SHA-1 provides a level of cryptographic security, Linus's main concern was data integrity, learning from issues encountered with BitKeeper's approach to data protection.

"And people kind of think that using the SHA-1 hashes was a huge mistake. But to me, SHA-1 hashes were never about the security. It was about finding corruption. Because we’d actually had some of that during the BitKeeper things, where BitKeeper used CRCs and MD5s, right, but didn’t use it for everything. So one of the early designs for me was absolutely everything was protected by a really good hash."

8. Git's low-level design is intentionally simple.

Linus drew a parallel to Unix's design philosophy, where a few fundamental ideas underpin a powerful and versatile system.

"Unix has like a core philosophy of everything is a process, everything is a file, you pipe things between things. And then the reality is it’s not actually simple. I mean, there’s the simple concepts that underlie the philosophy, but then all the details are very complicated. I think that’s what made me appreciate Unix in the first place. And I think Git has some of the same kind of, there’s a fundamental core simplicity to the design and then there’s the complexity of implementation."

9. Linus believes that the effort to support SHA-256 in addition to SHA-1 was largely a waste of time and resources, driven by unnecessary worry.

While understanding the concerns, he felt there wasn't a genuine need for the dual-hashing approach and that it led to "pointless churn."

"Well, I mean, SHA-1 I regret in the sense that I think it caused a lot of pointless churn with the whole “trying to support SHA-256 as well as SHA-1.” And I understand why it happened, but I do think it was mostly pointless. I don’t think there was a huge, real need for it, but people were worried, so it was short. So I think there’s a lot of wasted effort there."

10. During the initial development, Linus had a clear vision for the immediate steps but wasn't entirely certain about how all the pieces would ultimately fit together.

While he quickly achieved the ability to apply patches, other core functionalities like merging took more time and he wasn't always sure he would reach his goals.

"I had a clear idea of the initial stages but I wasn’t sure how it would work in the long run. So honestly, after the first week, I had something that was good for applying patches, but not so much for everything else. I had the basics for doing merges, and the data structures were in place for that, but it actually took, I think it took an additional week before I did my first merge. There were a number of things where I had kind of the big picture and result in mind, but I wasn’t sure if I’d get there."

11. The very first versions of Git were rudimentary because there was a more important project to prioritize.

The initial focus was on getting the core functionality working for kernel development, with robustness and more advanced features added over time.

"Yeah, the first steps, I mean the first week or two, I mean, you can go and look at the code — and people have — and it is not complicated code. I think the first version was 10,000 lines or something. You can more or less read it in a single sitting. Yeah, and it’s fairly straightforward and doesn’t do a lot of error checking and stuff like that. It’s really a, “Let’s get this working because I have another project that I consider to be more important that I need to get back to.” It really was."

12. Early Git usage involved direct manipulation of low-level "plumbing commands" and manual editing of files.

Basic operations like committing required arcane sequences of commands that directly interacted with Git's underlying object store.

"I mean, the first week when I was using it for the kernel, I was literally using the raw, what are now called “plumbing commands” by hand. Of course. Because there was no so-called porcelain. There was nothing above that to make it usable. So to make a commit, you’d do these very arcane things. Set your index, commit-tree. Yeah, commit-tree, write, and that just returns an SHA that you write by hand into the head file and that was it."

13. The hash-object command, fundamental for Git's content-addressable storage, was one of the earliest binary utilities Linus created.

This allowed him to verify the core hashing mechanism by manually hashing data and checking the output.

"I think that was one of the first binaries that I had where I could just check that I could hash everything by hand and it would return the hash to standard out, then you could do whatever you wanted to it."

14. The initial user interface "porcelain" for Git consisted of shell scripts written by Linus to wrap the difficult-to-use plumbing commands.

Making Git accessible required building higher-level tools on top of the core commands. Linus's initial attempts were in the form of simple scripts, which weren't particularly user-friendly.

"But it was like the early porcelain was me scripting shell scripts around these very hard-to-use things. And honestly, it wasn’t easy to use even with my shell scripts."

15. The first target audience for Git was the hardcore kernel developers who were already familiar with some of the concepts from using BitKeeper.

Their prior experience with a more advanced VCS made them more receptive to Git's underlying ideas.

"But to be fair, the first initial target audience for this were pretty hardcore kernel people who had been using BitKeeper. They at least knew a lot of the concepts I was aiming for. People picked it up."

16. Linus handed over the maintainership of Git to Junio Hamano relatively early in the project.

After only three or four months of his own stewardship, Linus recognized the need to focus on the kernel and trusted Junio's capabilities to lead Git's further development.

"I mean, to be honest, I maintained Git for like three or four months. I think I handed it off in August [of 2005] or something like that. And when I handed it off, I truly just handed it off. I was like, “I’m still around.” I was still reading the Git mailing list, which I don’t do anymore. Junio wanted to make sure that if he asked me anything, I’d be okay. But at the same time, I was like, this is not what I want to do."

17. Linus's criteria for choosing Junio as the maintainer was largely based on his "taste" in code.

He valued Junio's judgment and his understanding of the project's direction.

"But to be honest I’ll take credit for having worked with people on the internet for long enough that I was like — during the four months I was maintaining Git, I was pretty good at picking up who has got the good taste to be a good maintainer. That’s what it’s about — taste — for you. For me, it’s hard to describe. You can see it in patches, you can see it in how they react to other people’s code, “how they think” kind of things."

18. Git's distributed nature, where every repository is a full copy with complete history, was a key design principle.

This architecture made local work and later sharing incredibly easy. It also differentiated it from most previous centralized version control systems and contributed to its widespread adoption.

"So the distributed nature really ends up making so many things so easy and that was one big part that set Git apart from pretty much all SCMs before, was… I mean there had been distributed SCMs, but there had, as far as I know, never been something where it was like the number one design goal — I mean, along with the other number one design goals — where it means that you can work with Git purely locally and then later if you want to make it available in any other place it’s so easy. And that’s very different from, say, CVS where you have to set up this kind of repository and if you ever want to move it anywhere else it’s just very very painful and you can’t share it with somebody else without losing track of it."

19. Linus believes that Git's fundamental design, emphasizing easy copying and the equality of all repositories, made services like GitHub "trivial" at their core.

The underlying architecture of Git facilitated the creation of centralized hosting platforms.

"And the fact that Git didn’t do that, and very much by design didn’t do that, I mean that’s what made services like GitHub trivial. I mean I’m trivializing GitHub because I realized there’s a lot of work in making all the infrastructure around Git, but at the same time the basic Git hosting site is basically nothing because the whole design of Git is designed around making it easy to copy, and every repository is the same and equal."

20. Linus was amused by the initial wave of complaints about Git's user interface, particularly the naming of commands, as he sometimes deliberately chose different names than CVS simply because he disliked it.

The transition from older systems led to confusion and criticism, but Linus had his own reasons for some of the seemingly arbitrary choices.

"Oh, the complaints kept coming. Tell me about it. Oh, I mean, it’s more like I can’t point to details. You’d have to Google it. But the number of people who sent me, “Why does it do this?” And the flame wars over my choice of names. For example, I didn’t have git status, which actually is one of the commands I use fairly regularly now... So I just remember the first few years, the complaints about why the names of the subcommands are different for no good reason. And the main reason was I just didn’t like CVS very much, so I did things differently on purpose sometimes."

Final Words

So there you have it: 20 interesting facts about the early days of Git!

Here at Tower, as passionate fans and dedicated users of Git ourselves, we join the global community in celebrating this remarkable 20-year milestone. We recognize and appreciate the profound influence Git has had on our daily work and the collaborative spirit of software development as a whole.

Here's to many more years of Git! 🥂

We hope you found this post helpful. For more Git tips and tricks, don't forget to sign up for our newsletter below and follow Tower on Twitter / X and LinkedIn! ✌️