Git 10 Anniversary, founder Linus Torvalds interview

Ten years ago this week, the Linux kernel community faced a fundamental challenge: they were no longer able to use their repair control system: BitKeeper, while other software configuration management encountered new requirements for distributed systems. The founder of Linus Torvalds,linux, who took over the challenge and disappeared for weeks, created a Git tool. Today Git is used for thousands of projects, and a new wave of social coding has started in the programmer community.

To celebrate this milestone, we ask Linus to share the behind-the-scenes stories of Git and tell us about the impact of the software development of this team. You'll find him in the comments behind this story. Our followers q&a the path of git, and we depict the contours of other projects as well. To find the story behind Kvm,qt,drupal,puppet and wine.

Why Develop Git?

Torvalds: I don't really want to do source control, I think source management is the most boring thing in the computer field (maybe the database is more boring; ^). I am angry with SCM (source Control tool). But the appearance of BitKeeper let me re-understand the source management. Most of BK (BitKeeper) is correct, but a repository with a local copy and a distributed merge is a big problem. One of the main problems with distributed source management is the separation of source management--who can commit changes. BK shows how to avoid this problem by having a source library for everyone. But BK also has its own problems: several techniques lead to this problem (annoying renaming), but the biggest problem is that it does not open source, which makes many people reluctant to use it. So when we ended up using BK with a few cores of maintenance-they were free-to-use open source projects-but they were everywhere. BK helps the kernel developer, but it still has a pain point.

When Tridge (Andrew Tridgell) reverse engineered the (rather simple) BK protocol – This is contrary to BK's rules of use – things have to be resolved. I spent a few weeks (a few months?) I think that's the way to mediate between Tridge and Larry McVoy, but in the end, it obviously doesn't make any difference. So, from that moment on, I decided not to use BK any more, than to go back to the bad days before I used BK. At the same time, it is regrettable that some other SCM is trying to do the distributed thing, but the remote access is not handled well. I have a performance requirement, not just to meet remote availability, but also to worry about code integrity and the entire workflow, so I decided to write one myself.

How did you go about doing it? Are you writing code for the entire weekend, or just for a few hours at a fixed hour?

Torvalds: Hey, actually, you can see how it's shaped in Git's source code repository, except probably the very beginning of the day. It took me about a day to get git to "self-control" (self-hosting) so that I could commit the code (commit) to Git via git. So maybe the first day is hidden, but all the other things are there. Coding works Most of the day, but there are a few at midnight, and there are some at 2 o'clock in the morning. The most interesting part of it is that it's shaped very fast; the first commit in the Git tree doesn't have a lot of code, but it has done the most basic thing – it can commit itself. The trick is actually not in code, but in figuring out how it organizes the data.

So, I want to say that git looks after about 10 days (at this point, I used git to do the first commit of *kernel*), and it's not like some crazy garbage coding (it has actual use value). The early code volume is actually very small, and its goal is to correctly implement the basic point. I've been thinking it over before the whole project started. I realized that other people had problems and thought of things to avoid.

Does it have a period of existence that meets your expectations? How do you think it should work at the moment? Are there some restrictions?

Torvalds: I'm very happy with git. For the development of kernel, it did very, very well, satisfying all my expectations. What's interesting to me is how it took over many other projects. The result is startling. There is a lot of inertia in changing the source control system, and look at CVS, even RCS, for how long they occupy, but at some point git takes over.

Why do you think it is so widely adopted?

Torvalds: I think many others, like me, are frustrated by the same problems that make me dislike SCM. Many projects have been maddening by trying to solve a small problem with one or two edge corners, not really tackling important issues like git. Even if people don't know how important the "distributed" part is (many people have objected to it), as long as they understand that git allows simple and reliable backups while allowing people to build their own private repositories without worrying about the policy of having write access to some central repositories, they will never return to the previous version management.

Will git be there forever? Or, do you foresee that there will be other version control systems coming up in the next 10 years? Will you be one of the authors of this system?

Torvalds: No, I'm not going to be one of these writers. We may be able to see something new in 10 years, but I'm sure these things will be "git-like." This is not to say that git handles everything correctly, but it solves the most basic problems in an unprecedented way, before which no software configuration management tool (SCM) can rival it.

I can say without modesty;)

Why can git work so well on Linux?

Torvalds: Well, obviously it's designed for our workflow, so he's a part of Linux. I have mentioned the full "distributed" section many times, but it is worth mentioning again and again. It was designed to be efficient in the face of large projects like Linux, and it was designed to accomplish tasks that were considered "difficult" before it-because I do it every day.

Just one example: the concept of code merging is often considered a very painful and difficult thing in most source management tools. You'll plan your code consolidation, because that's a big decision. That's not acceptable to me, and since I've done dozens of code merges in front of the merged window a day, the biggest headache is not the code merge work itself, but the most important thing is to check the results. In Git, code merging takes only a few seconds, and it can take me a long time to write code to merge comment text.

So git is basically designed and coded to meet my needs.

Some say git was designed for smart people, and even Andrew Morton said: "Git has been deliberately designed to make you feel smart." "How do you respond to this?"

Torvalds: I think it did before, but it's different now. For some reason, people find git hard to use, but I think there's only one reason for this: you can do it in many different ways.

With Git you can do a lot of things. Please, git requires people to obey a lot of rules that are not technically limited, but to allow people to collaborate better. Git is a powerful tool that you will feel very difficult to get started with, usually because you can do one thing in different ways, and these methods work! In general, the best way to learn about git might be to use it to do the most basic things until you're familiar with the basics and learn about other uses of Git.

There are some historical reasons for the complexity of Git, one of which is that it used to be complicated! Early users of Git were those who programmed for kernel, who had to learn a series of very difficult scripts. Spend most of your energy on making git work, not more. So the early git impression (really) is that you have to know exactly what you're doing. Of course, in the first six months or a year, the truth is true.

Another reason people feel git is complicated: git differs from the previous SCM. Many people use CVS for ten years or even 20 years, but git is not CVS, and they are nothing like that. Git and CVS have different design concepts and commands. Git has never thought of mimicking CVs, or even vice versa. If you've ever used a CVS-style SCM system for a long time, you'll feel that git is complicated and that there's no need for a design that differs from CVS. The odd revision number will distract you, and you wonder: Why does Git's revision number not add up like CVS 1.3.1, and choose a strange 40-byte hexadecimal number?

But git doesn't have to be deliberately unconventional. Git does differ from CVS because people have different backgrounds, so these differences make one feel more complicated than the other. CVS backgrounds are fading away, and maybe now many people who have used git have never used CVS, and they're not used to the way CVS works.

Do you think there is no git,linux kernel can achieve the current development speed?

Torvalds: Well, there's no git, I think I can. But that means someone needs to write a tool similar to GIT: a distributed SCM that is as efficient as git. Yes, we do need things like git.

What do you think of GitHub now?

Torvalds: No doubt, GitHub is a great code hosting service, but I still have some ideas about it: as a development platform (submitting code, requesting updates, tracking issue, etc.), GitHub has too many restrictions. It's far less impressive than the kernel development platform.

Part of the reason is that kernel's development approach is--git for kernel development, but another part of the reason is that GitHub's interface encourages bad behavior. For example, "complete commit" on GitHub has some bad submission information. GitHub has fixed some issues, and maybe it's done well now, but it's never a perfect combination of git, like Linux kernel.

Would you please tell me about your most interesting usage on Git or GitHub?

Torvalds: It's nice to see that using git makes it easy to create a project. Previous code hosting was hard to use, and with Git and GitHub, it was easy to create small projects. It doesn't matter what the project does, it's important that you can do it.

Do you have any other projects recently? Other great projects that can dominate software development over the next few years?

Torvalds: Not at the moment, I'll tell you if there is.

Git 10 Anniversary, founder Linus Torvalds interview