881
Ten years Git: an interview with the creator - Linus Torvalds
This week was ten years from the date when the Linux kernel developers are faced with an obstacle: they could no longer use its version control system BitKeeper and no other source code control system did not meet their requirements in terms of distributed resources. Linus Torvalds, creator of Linux, accepted the challenge and disappeared over the weekend to appear next week with Git. Today, Git is used in thousands of projects and Git pushed programming in groups of developers to the new social level.
To mark this date, we asked Linus to share the hidden history of the creation of Git, tell us what he thinks about this project and its impact on the development of software products. You will find it in the comments below the text. For this interview the following weeks, Git, where every day we will consider individual projects that use the version control system. Expect stories develop KVM, Qt, Drupal, Puppet, Wine, and many others.
Why did you set up Git?
Torvalds: In fact, I never wanted to do version control system (SLE) and felt that it was just the least interesting thing in the computer world (with the possible exception of databases; ^) and I passionately hated all such systems. But then came BitKiper (BK) and really changed the way I looked at the source code control. BK did many things right. And the ability to keep at a local copy of the repository and distributed merge code was a good thing. An important feature of the distributed version control model is that it eliminates one of the most serious problems SLE - a policy of who can make changes. BK has shown that you can avoid it simply by distributing all repository. But BK had its own problems; Several technical solutions leads to a problem (name change was painful), but the worst was the fact that, since BK is not distributed with open source software, and it was a lot of people who do not want to use it. So we ended up that there were several major developers using BK, which was free for use in open source projects, but it never became generally accepted. So it's (VC) has helped in the development of the kernel, but there still remained sick moments.
It occurred to me when Tridge (Andrew Tridgell) began to reverse-engineer a simple protocol BK, that was a violation of the rules of use of BK. I spent a few weeks (months? That's how I felt myself and) trying to mediate between the Tridge and Larry McVoy, but eventually it became clear that it simply does not work. So, at some point, I just decided that I can no longer continue to use BK, but I also do not want to go back to the worst days that were before the BK. It is sad that while there were other tools for SLE, which to some extent tried to use a distributed development model, but none of them worked well in the case of remote use. I had my own performance requirements, which are approximately even could not be satisfied with what was available; and I'm also worried about the integrity of the code and the design process, so I decided to write his.
How you came to this? You wrote it all weekend or just the usual time?
Torvalds: Eh. You, by the way, you can see how it all took the form of a source code repository Git, except for the first day or something like that. The day was spent trying to become a Git itself to host so that you can start using Git commits in Git. Therefore, the first day or something like that is not present in the story, but everything else - there. The main work was carried out mainly during the daytime, but there are a couple of records and a pair of midnight - after two o'clock in the morning. The most interesting thing is how fast it took the form. The very first commit in the tree Git - it's not a lot of code, but it does the basic - enough to commit an of itself. The trick was not so much coding as to understand how Git has to organize the data.
I would like to emphasize that despite the fact that it has been collected for ten days or something like that (during which I made my first Git commit to the repository Linux kernel), it was not in any way crazy coding. The volume of this early code is small enough, everything depended on the correct implementation of the basic ideas. And so I spent some time "grinds" before the entire project was launched. I have seen the problems of others. I saw what I wanted to avoid.
Whether it increased (Git) to the level of your expectations? How well it (Git) works on your estimates? Are there any restrictions?
Torvalds: I am very pleased with Git. It works exceptionally well with the kernel code and still be my expectations. What is interesting is the fact that it took so many other projects. Surprisingly quickly in the end. There is a lot of inertia in switching from one to the other SLE; Just look how long remained in use even CVS and RCS, but at some point, Git and took their case.
What do you think, why is it (Git) has been so widely adopted in use?
Torvalds: I think a lot of people were annoyed by the same problems that made me hate SLE. And while there were many projects in an attempt to fix one or two small problems that lift people out of themselves, in fact there was nothing such as Git, that really helped no longer take the big problems in his head. Even when people do not understand how important a distributed development model (and many people struggled with this), then as soon as they realized that it allows for more light and reliable backups and allows people to make their own repository without having to think about politics in the recording resolution certain repository, they never looked back.
Will Git always exist, or you anticipate a revision of SLE in the next ten years? Will you be one of those who write it?
Torvalds: No, I'll be the one to write it. And maybe we'll see something new for ten years, but I guarantee that it will be something quite Git-like. Not in the sense that in Git it right, but in the sense that Git has the basic features right inside that other SLE previously never had.
Without false modesty;)
Why Git works so well in Linux?
Torvalds: Well, Git was created for our work, because it is part of it. I have already mentioned a distributed model many times, but it makes sense once again to recall it. But Git has also been established to be quite effective for a large project like Linux, and is written to do what people considered a challenge before the advent of Git - because these are the things that I do every day.
Just for example: the concept of the merger was seen as something very painful and difficult in many SLE. You would have had to plan their draining, because they were serious business. This is not ustaivaet me since I usually do dozens of mergers in the day when I am in a time window of the merger, and even then, the workload should not be in the merger, and testing code. The merger itself takes a couple of seconds, it is much more interested in writing explaining the merger.
So, Git was built and written for my requirements. And so it happens.
People said that Git - only for the super smart people. Even Andrew Morton (Andrew Morton) said that Git «Git designed to make you feel even more stupid than before." What would be your response to that?
Torvalds: Well, I think it was at first, but this is no longer the case. There are several reasons why people feel so, but I think that is only one reason to stay. The one that remains, is very simple: "you can do so in different ways».
You can do many things using Git, and many of the rules about what you should do not come from technical limitations, but because so works well when you have to interact with other people. Git is a very powerful set of tools that can overload the beginning, but it also means that you can often do the same or similar things in different ways and they all worked. In general, the best way to learn Git, probably, is to just do the simple things and do not even look at other things as long as you're not confident with regard to the basics.
There are several historical reasons for the perception of Git as a complex thing. One of them - the fact that it was really difficult. Those people who started using Git before anyone else to work with the Linux kernel, really had to learn to use a rather complicated set of scripts to make everything work. All efforts were aimed at to get to work the core technology and quite a bit - in fact, to make it easy or obvious. And Git, of course, had a reputation which provided knowledge of what you were doing before. However, it was generally true only during the first six months or a year.
Another reason that people felt like Git - a complicated thing that Git is very peculiar. There are people who enjoy such things as CVS for a decade or two, and Git - not CVS. Not even similar. Different concepts. Teams differ. Git never tried to look like CVS, and vice versa. And, if you used the CVS-like system for a long time, it gives the impression of complexity and causeless differences Git. People were repulsed strange system version numbers. Why is the version number of Git «1.3.1», but not as nice done with increasing numbers in the versions of CVS? Why are there (Git) strange and terrible 40-digit number in hexadecimal?
But Git was not unreasonably others. These differences were necessary. Most likely, people just think that Git is more complicated than it really is, simply because they come with other baggage of experience. CVS leaves background. At the moment, probably, there are many programmers who have never used CVS in their lives and they can find it, how it works CVS, very confusing simply because they have learned in the first place Git.
Could speed the development of the Linux kernel to grow with the existing speed without Git? Why?
Torvalds: Well, "without git» - of course. But it would have provided for the fact that someone would write an equivalent Git: some distributed SLE, which would be as effective as, and 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. Complaint that I had was the fact that as a development platform GitHub - commits pull-rekvest, tracing the history of problems and so on - is not working well enough. It's not even close, not like for something like the Linux kernel. Too limited.
This is partly on how the Linux kernel is developed, but partly also because the interfaces to GitHub actively encourage bad behavior. Commits made on GitHub comments contain these commits, and so on, simply because the web interface on GitHub actively encouraged to bad behavior. They fixed some of these things, so that probably works better, but it will never be suitable for something like the Linux kernel.
What is the most interesting use Git and / or GitHub you met?
Torvalds: I am very pleased that he (Git) so facilitated the launch of new projects. Hosting the project earlier delivered a lot of pain, but with the advent of Git and GitHub make any small project it was so easy. No matter what the project is, what matters is what you can do.
Do you have any side projects "in the hole"? Some wonderful projects that will dominate in software development for the next years?
Torvalds: Nothing is planned. But I'll let you know if these plans have changed.
ps: advice and suggestions are welcome to transfer in order to improve the quality of translation.
Source: geektimes.ru/post/248744/
To mark this date, we asked Linus to share the hidden history of the creation of Git, tell us what he thinks about this project and its impact on the development of software products. You will find it in the comments below the text. For this interview the following weeks, Git, where every day we will consider individual projects that use the version control system. Expect stories develop KVM, Qt, Drupal, Puppet, Wine, and many others.
Why did you set up Git?
Torvalds: In fact, I never wanted to do version control system (SLE) and felt that it was just the least interesting thing in the computer world (with the possible exception of databases; ^) and I passionately hated all such systems. But then came BitKiper (BK) and really changed the way I looked at the source code control. BK did many things right. And the ability to keep at a local copy of the repository and distributed merge code was a good thing. An important feature of the distributed version control model is that it eliminates one of the most serious problems SLE - a policy of who can make changes. BK has shown that you can avoid it simply by distributing all repository. But BK had its own problems; Several technical solutions leads to a problem (name change was painful), but the worst was the fact that, since BK is not distributed with open source software, and it was a lot of people who do not want to use it. So we ended up that there were several major developers using BK, which was free for use in open source projects, but it never became generally accepted. So it's (VC) has helped in the development of the kernel, but there still remained sick moments.
It occurred to me when Tridge (Andrew Tridgell) began to reverse-engineer a simple protocol BK, that was a violation of the rules of use of BK. I spent a few weeks (months? That's how I felt myself and) trying to mediate between the Tridge and Larry McVoy, but eventually it became clear that it simply does not work. So, at some point, I just decided that I can no longer continue to use BK, but I also do not want to go back to the worst days that were before the BK. It is sad that while there were other tools for SLE, which to some extent tried to use a distributed development model, but none of them worked well in the case of remote use. I had my own performance requirements, which are approximately even could not be satisfied with what was available; and I'm also worried about the integrity of the code and the design process, so I decided to write his.
How you came to this? You wrote it all weekend or just the usual time?
Torvalds: Eh. You, by the way, you can see how it all took the form of a source code repository Git, except for the first day or something like that. The day was spent trying to become a Git itself to host so that you can start using Git commits in Git. Therefore, the first day or something like that is not present in the story, but everything else - there. The main work was carried out mainly during the daytime, but there are a couple of records and a pair of midnight - after two o'clock in the morning. The most interesting thing is how fast it took the form. The very first commit in the tree Git - it's not a lot of code, but it does the basic - enough to commit an of itself. The trick was not so much coding as to understand how Git has to organize the data.
I would like to emphasize that despite the fact that it has been collected for ten days or something like that (during which I made my first Git commit to the repository Linux kernel), it was not in any way crazy coding. The volume of this early code is small enough, everything depended on the correct implementation of the basic ideas. And so I spent some time "grinds" before the entire project was launched. I have seen the problems of others. I saw what I wanted to avoid.
Whether it increased (Git) to the level of your expectations? How well it (Git) works on your estimates? Are there any restrictions?
Torvalds: I am very pleased with Git. It works exceptionally well with the kernel code and still be my expectations. What is interesting is the fact that it took so many other projects. Surprisingly quickly in the end. There is a lot of inertia in switching from one to the other SLE; Just look how long remained in use even CVS and RCS, but at some point, Git and took their case.
What do you think, why is it (Git) has been so widely adopted in use?
Torvalds: I think a lot of people were annoyed by the same problems that made me hate SLE. And while there were many projects in an attempt to fix one or two small problems that lift people out of themselves, in fact there was nothing such as Git, that really helped no longer take the big problems in his head. Even when people do not understand how important a distributed development model (and many people struggled with this), then as soon as they realized that it allows for more light and reliable backups and allows people to make their own repository without having to think about politics in the recording resolution certain repository, they never looked back.
Will Git always exist, or you anticipate a revision of SLE in the next ten years? Will you be one of those who write it?
Torvalds: No, I'll be the one to write it. And maybe we'll see something new for ten years, but I guarantee that it will be something quite Git-like. Not in the sense that in Git it right, but in the sense that Git has the basic features right inside that other SLE previously never had.
Without false modesty;)
Why Git works so well in Linux?
Torvalds: Well, Git was created for our work, because it is part of it. I have already mentioned a distributed model many times, but it makes sense once again to recall it. But Git has also been established to be quite effective for a large project like Linux, and is written to do what people considered a challenge before the advent of Git - because these are the things that I do every day.
Just for example: the concept of the merger was seen as something very painful and difficult in many SLE. You would have had to plan their draining, because they were serious business. This is not ustaivaet me since I usually do dozens of mergers in the day when I am in a time window of the merger, and even then, the workload should not be in the merger, and testing code. The merger itself takes a couple of seconds, it is much more interested in writing explaining the merger.
So, Git was built and written for my requirements. And so it happens.
People said that Git - only for the super smart people. Even Andrew Morton (Andrew Morton) said that Git «Git designed to make you feel even more stupid than before." What would be your response to that?
Torvalds: Well, I think it was at first, but this is no longer the case. There are several reasons why people feel so, but I think that is only one reason to stay. The one that remains, is very simple: "you can do so in different ways».
You can do many things using Git, and many of the rules about what you should do not come from technical limitations, but because so works well when you have to interact with other people. Git is a very powerful set of tools that can overload the beginning, but it also means that you can often do the same or similar things in different ways and they all worked. In general, the best way to learn Git, probably, is to just do the simple things and do not even look at other things as long as you're not confident with regard to the basics.
There are several historical reasons for the perception of Git as a complex thing. One of them - the fact that it was really difficult. Those people who started using Git before anyone else to work with the Linux kernel, really had to learn to use a rather complicated set of scripts to make everything work. All efforts were aimed at to get to work the core technology and quite a bit - in fact, to make it easy or obvious. And Git, of course, had a reputation which provided knowledge of what you were doing before. However, it was generally true only during the first six months or a year.
Another reason that people felt like Git - a complicated thing that Git is very peculiar. There are people who enjoy such things as CVS for a decade or two, and Git - not CVS. Not even similar. Different concepts. Teams differ. Git never tried to look like CVS, and vice versa. And, if you used the CVS-like system for a long time, it gives the impression of complexity and causeless differences Git. People were repulsed strange system version numbers. Why is the version number of Git «1.3.1», but not as nice done with increasing numbers in the versions of CVS? Why are there (Git) strange and terrible 40-digit number in hexadecimal?
But Git was not unreasonably others. These differences were necessary. Most likely, people just think that Git is more complicated than it really is, simply because they come with other baggage of experience. CVS leaves background. At the moment, probably, there are many programmers who have never used CVS in their lives and they can find it, how it works CVS, very confusing simply because they have learned in the first place Git.
Could speed the development of the Linux kernel to grow with the existing speed without Git? Why?
Torvalds: Well, "without git» - of course. But it would have provided for the fact that someone would write an equivalent Git: some distributed SLE, which would be as effective as, and 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. Complaint that I had was the fact that as a development platform GitHub - commits pull-rekvest, tracing the history of problems and so on - is not working well enough. It's not even close, not like for something like the Linux kernel. Too limited.
This is partly on how the Linux kernel is developed, but partly also because the interfaces to GitHub actively encourage bad behavior. Commits made on GitHub comments contain these commits, and so on, simply because the web interface on GitHub actively encouraged to bad behavior. They fixed some of these things, so that probably works better, but it will never be suitable for something like the Linux kernel.
What is the most interesting use Git and / or GitHub you met?
Torvalds: I am very pleased that he (Git) so facilitated the launch of new projects. Hosting the project earlier delivered a lot of pain, but with the advent of Git and GitHub make any small project it was so easy. No matter what the project is, what matters is what you can do.
Do you have any side projects "in the hole"? Some wonderful projects that will dominate in software development for the next years?
Torvalds: Nothing is planned. But I'll let you know if these plans have changed.
ps: advice and suggestions are welcome to transfer in order to improve the quality of translation.
Source: geektimes.ru/post/248744/
