This week will be ten years from the moment when the Linux kernel developers ran into interference: they could no longer use their BitKeeper version control system and no other source code control system met their requirements in terms of resource allocation. Linus Torvalds, the creator of Linux, accepted the challenge and disappeared over the weekend in order to appear with Git next week. Today, Git is being used in thousands of projects and Git has pushed programming in development teams to a new social level.

To celebrate this date, we asked Linus to share the hidden history of creating Git, to tell us what he thinks about this project and its impact on the development of software products. You will find his comments below in the text. This interview will be followed by a week of Git, in which every day we will consider individual projects using this version control system. Expect development history of KVM, Qt, Drupal, Puppet, Wine and many others.

Why did you create git?

Torvalds: Actually, I never wanted to deal with the version control system (SLE) and felt that it was just the least interesting thing in the computer world (perhaps with the exception of databases; ^), and I passionately hated all such systems. But then BitKiper (BK) appeared and, indeed, changed the way I considered controlling the source code. BK did many things right. And the ability to keep a local copy of the repository and distributed code merging was good stuff. An important feature of the distributed version control model is that it eliminates one of the most serious problems of hard currency - the policy of who can make changes. BK has shown that you can avoid it by simply distributing the repository to everyone. But BK had its own problems; several technical solutions led to problems (renaming was painful), but the worst was the fact that since BK did not spread with open source, there were many people who did not want to use it. So we ended up with a few major developers using BK, which was free to use in open source projects, but it never became generally accepted. So this (VC) helped in the development of the core, but there still remained sore moments.
')
It occurred to me when Tridge (Andrew Tridgell) began reverse engineering a fairly simple BK protocol, which was a violation of the rules for using BK. I spent a few weeks (months? So I felt myself) trying to mediate between Tridge and Larry McVoy, but in the end it became clear that it simply did not work. So at some point, I just decided that I could no longer continue using BK, but I also don’t want to go back to the worst days that were before BK. It’s sad that there were other SLE tools that tried to use a distributed development model to some extent, but none of them worked well for remote use. I had my own performance requirements, which even approximately could not be satisfied with what was available; and I was also worried about the integrity of the code and the development process, so I decided to write my own.

How did you approach this? Did you write it all weekend or only during normal time?

Torvalds: Eh. By the way, you can see how everything took shape in the Git source code repository, except for the first day or something like that. The day was spent in order for Git to host itself so that you can start committing to Git using Git. Therefore, the first day or something like that is not present in history, but everything else is there. Most of the work was done during the daytime, but there are a couple of midnight notes and a couple after two in the morning. The most interesting thing is how quickly it took shape. The very first commit in the Git tree is not a lot of code, but it did the main thing - enough to commit itself. The trick was not so much in coding as in understanding how Git should organize data.

I would like to emphasize that despite the fact that it was compiled within ten days or something like this (during which I made my first Git commit to the Linux kernel repository), it was by no means crazy coding. The volume of this early code is rather small, everything depended on the correct implementation of the main ideas. And so, I “grinded” for a while before the whole project was launched. I have seen the problems of others. I saw what I wanted to avoid.

Has this (git) grown up to your expectations? How well does this (git) work according to your estimates? Are there any restrictions?

Torvalds: I am very pleased with Git. It works exceptionally well with kernel code and still follows my expectations. What is interesting is that he accepted so many other projects. Surprisingly quickly, after all. There is a lot of inertia in switching from one SLE to another; Just look at how long CVS and even RCS remained in use, but at some point Git accepted their work.

Why do you think this (Git) was so widely accepted?

Torvalds: I think many people were annoyed by the very same problems that made me hate SLE. And although there were many projects in an attempt to fix one or two minor problems that put people out of themselves, in reality there was nothing like Git that really helped no longer take big problems to their head. Even when people did not understand how important a distributed development model (and many people struggled with this), as soon as they realized that it allows you to make lighter and more reliable backups and allows people to create their own repositories without having to think about writing permissions policy in certain repository, they never looked back.

Will Git always exist or do you anticipate a revision of hard currency over the next ten years? Will you be one of those who write it?

Torvalds: No, I will not be the one who writes it. And, perhaps, we will see something new in ten years, but I guarantee that it will be something quite Git-like. Not in the sense that everything in Git is correct, but in the sense that Git has basic capabilities right inside, which other hard currency never had before.

No fake modesty;)

Why does git work so well in linux?

Torvalds: Well, Git was created for our work, because it is part of it. I have already mentioned the distributed model many times, but it makes sense to recall it again. But Git was also created to be efficient enough for a large project like Linux, and written to do what people considered difficult before the advent of Git - because these are the things that I do every day.

Just for example: the concept of merging was viewed as something very painful and complex in many SLE. You would have to plan your mergers, because they were a serious matter. This does not bother me, since I usually do dozens of merges per day when I am in the merge time window, and even so, the workload should not be in the merger, but in code testing. A merge in itself takes a couple of seconds, much more it takes to write an explanation of the merger.

So Git was built and written for my requirements. This is what happens.

People said that Git is only for super smart people. Even Andrew Morton said that Git "Git is designed to make you feel even more stupid than before." ² . What will be your answer to this?

Torvalds: Well, I think it was like that at first, but this is no longer the case. There are several reasons why people feel this way, but I think that only one reason remains. The one that remained is very simple: “this can be done in such a different way”.

You can do a lot of things with Git, and many of the rules about what you have to do come not from technical limitations, but because it works well when you have to interact with other people. Git is a very powerful set of tools that can overload at the beginning, but it also means that you can often do the same or similar things in different ways and they all work. In general, the best way to learn Git is probably to just do simple things and not even look at other things until you are confident about the basics.

There are several historical reasons for seeing Git as a complex thing. One of them is that it really was difficult. Those people who started using Git before anyone else to work with the Linux kernel really had to learn how to use a rather complicated set of scripts to make everything work. All forces were aimed at making basic technology work and quite a bit at making it easy or obvious. So Git, of course, had a reputation which provided for knowing what you did before. But this was mostly true only for the first six months or a year.

Another reason why people thought Git was complex is that Git is very peculiar. There are people who have used such things as CVS for a decade or two, and Git is not CVS. Do not even look like. Different concepts. Teams vary. Git never tried to look like CVS, or vice versa. And, if you have used a CVS-like system for a long time, then you get the impression of the complexity and gratuitous difference of Git. People were pushed aside by a strange version number system. Why is the Git version number "1.3.1", and not so nicely done with increasing numbers in CVS versions? Why is there (in Git) a weird and scary 40-character number in hexadecimal?

But Git was not without any reason. These differences were needed. Most likely, people just think that Git is more complex than it really is, simply because they come with a different baggage of experience. Background CVS goes away ¹ . At the moment, there are probably many programmers who have never used CVS in their life and can find how CVS works to be very confusing simply because they studied Git first.

Could a Linux kernel development speed grow at an existing rate without Git? Why?

Torvalds: Well, "without git" - of course. But this would entail the fact that someone would write some equivalent of Git: some kind of distributed hard currency that would be as effective as Git. We definitely needed something like git.

What is your current opinion on github?

Torvalds: Github is an exceptional resource for hosting; I have absolutely nothing against him. The complaints I had were that GitHub as a development platform — commits, pull requests, tracking problem history, and so on — does not work well enough. This is not even close, not suitable for something like a Linux kernel. Too limited.

This is partly how the Linux kernel is designed, but partly because the GitHub interfaces actively stimulate bad behavior. The commits made on GitHub contained comments on these commits, and so on, simply because the GitHub web interface was actively stimulating bad behavior. They fixed some of these things, so it probably works better, but it will never be suitable for something like a Linux kernel.

What is the most interesting use of git and / or github you have met?

Torvalds: I am very glad that he (Git) made it so easy to launch new projects. Hosting a project used to cause a lot of pain, but with the advent of Git and GitHub, it became so easy to make any small project. No matter what the project is, what you can do is important.

Do you have side projects "up your sleeve"? Any great projects that will dominate software development for the next years?

Torvalds: Nothing planned. But I will let you know if these plans change.

ps: tips and suggestions for translation are welcome in order to improve the quality of translation.

¹ @spmbt suggested an alternative and equally convincing translation of this sentence: “The previous experience with CVS is leaving.”
² @LampTester below mentioned the best translation of this phrase: "Git is purposely made so that you feel more stupid than you are."