First part of the interview.
Distributed version control system Git
JA: Linux is just the first of your projects to globally impact the world of open source. In 2005, you also created Git, an extremely popular distributed version control system. You quickly moved your Linux kernel source tree from the proprietary Bitkeeper repository to the newly minted Git, which you made open-source, and that same year you transferred Git support to Junio Hamano . The history of these events is fascinating, tell us what prompted you to hand over this project so quickly, and how did you find and choose Junio?
LT: So the answer to this question has two parts.
First, I absolutely didn't want to create a new source control system. Linux was created because I was very interested in the low-level interface between hardware and software - in principle, this work was done out of love for the subject and personal interest. On the contrary, Git was created out of necessity: not because I was interested in source control, but because most of the version control systems available at that time gave me a real disgust, and the one that seemed to me the most bearable and at the same time really worked very well. with the Linux development model (BitKeeper) became bankrupt.
Bottom line: I have been working on Linux for over 30 years (there are still a couple of months before the anniversary of the first release , but I started working on what later became Linux more than 30 years ago), and all this time I have been supporting it. But Git? I didn't even think about how to maintain it in the long run. I definitely like it, and of course I think it is the best source control system available, but it is not my big love and passion, if you know what I mean.
So I always wanted to find someone to maintain this source control system for me; in fact, I would be happy not to write it at all.
This is the context.
As for Junio - in fact, he is one of the first to really get into Git development. The first changes from him came to me within a few days after I released the very first (and very raw) version of Git to the public. Therefore, Junio has been involved in this project, one might say, from the very early days of Git.
But don't think that I just passed the project over to the first person I met. I have been maintaining Git for several months, and what prompted me to ask Junio if he would like to take over this support is the subtle sense of "good taste." Indeed, I cannot describe it more precisely: programming is reduced to solving technical problems, but the point is howyou solve them, and this is one of those things that start to be recognized over time: certain people have "good taste" and therefore choose the "right" solution.
I don’t want to say that programming is an art, because in reality programming is basically good engineering. I deeply believe in Thomas Edison's mantra of "one percent talent and ninety-nine percent diligence"; almost the whole point of success lies in small details and daily routine work. But, nevertheless, sometimes you have to show "inspiration" and that "good taste", that is, not just solve the problem, but solve it cleanly, accurately and yes, even beautifully.
Junio has such a "good taste".
Whenever it comes to Git, I remember to be very clear about this: While I pioneered Git and designed its core ideas, I often get overwhelming recognition for it. This was over 15 years ago, and I was only really immersed in Git for the first year. Junio is exemplary in supporting Git, and it is because of him that Git is what it is today.
By the way, this whole story with "good taste" and looking for people who have it, as well as with the ability to trust these people - applies not only to Git, but to no less extent to the entire history of Linux. Unlike Git, Linux is a product that I still support. I am actively engaged, but what Linux is in many ways similar to Git is the involvement of a huge number of people in the project. I think one of the great things about Linux is that there are literally hundreds of active contributors supporting it, and all of them, who are responsible for different parts of the kernel, have this hard-to-define "sense of taste."
JA: Have you ever delegated support to someone and then realized that this decision was wrong?
LT: The structure of our support work has never been so black and white or inflexible that it gives us any problems. In fact, it is unlikely that we will ever try to thoroughly document the support procedure. Yes, we have a MAINTAINERS file, but it was created so that you can finding the right people is not really a sign of some kind of exclusive possession.
Therefore, the whole structure “who owns what” is mostly plastic and intended for orientation, it means “this person is active and does his job well”, and not “oops, we entrusted the person with the project, but he took it and screwed everything up”.
The situation is also plastic in the sense that maybe you are supporting one subsystem, but you need to pick up something from another system - so, these boundaries are permeable. Usually such things are first actively discussed with people, and only then they are done, but the point is that there is such a practice, and there are no hard rules like “you can only touch this file”.
In fact, here we revisit the licensing topic raised in Part 1 and highlight one of the principles by which Git is designed, which is "everyone has their own tree, and technically no tree is special."
Since so many other projects have used tools like CVS or SVN - fundamentally some people do become special and take advantage of the "possession" that comes with that status. In the BSD world, this phenomenon is called the "commit bit": this is the bit, the owner of which has the right to commit code to the central repository (or at least some parts of it).
I have always hated this model, as it inevitably affects politics and creates a clique in the developer community where some people become privileged and trusted by default. The problem is not even that they “trust by default”, but just in the other side of the coin: they don’t trust someone, other people , and they, by definition, turn out to be outsiders who need to go through one of the “guards” to get the job done. ".
Again, this is not the case in Git. Everyone is equal. Everyone can clone a branch, start their own development, and if they do a good job, then when they merge, their branch can return to the main one, and if very well, then they are entrusted with support, and they are the ones who begin to be responsible for merging the code in those trees. for which they are responsible;).
Therefore, there is no need to endow people with special privileges, such a "bit of confirmation." It also means that no commit policy arises, no one has to “trust by default”. If it turned out that someone did a bad job, or, more often, the person simply lost interest in the project and found the job more interesting - their work will not get into the main branch when merging, and they will not get confused under the feet of others who can offer new, fresh ideas.
JA: Have you ever been impressed with the new features of Git, and have you incorporated them into your workflows? Can you name the features that, in your opinion, are still missing in Git?
LT: of course, first of all, it was my wishes for functionality that were satisfied, so I rarely had to think about any new features.
Git has definitely improved over the years, and some of these improvements have been reflected in my workflows as well. For example, Git has always been very fast - after all, that was one of the design goals I set out to do, but a lot of the work was originally done in shell scripts organized around some basic helper programs. Most of these shell scripts have gone over the years, which means that I can apply Andrew Morton's patch kits even faster than I originally did. This is very encouraging, since it was the speed of working with patches that I used as one of the first benchmarks in performance testing.
So, for me, Git has always been good, but it only got better over time.
Significant the improvements are related to how much more comfortable it became for "regular users" to work with Git. Largely due to the fact that people figured out how the task flow works in Git, and just got used to it (it is very different from CVS and other analogs that people are used to before), but Git itself has become much more pleasant to use.
Cloud servers from Macleod are fast and secure.
Register using the link above or by clicking on the banner and get a 10% discount for the first month of renting a server of any configuration!
