Linus Torvalds on Git at Google Tech Talk Conference Transcript. This event took place on May 3, 2007.
Andrew: Thank you for coming, everybody. Some of you have probably already heard of Linus Torvalds. Those of you who haven’t, you’re the people with Macintoshes on your laps.
He’s a guy who delights in being cruel to people. His latest cruel act is to create a revision control system which is expressly designed to make you feel less intelligent than you thought you were.
Thank you for coming down today, Linus. I’ve been getting emails for the past few days from people saying, where’s Linus? Why hasn’t he measured my tree? Doesn’t he love me anymore? And he walked into my office this afternoon. What are you doing here? But thank you for taking the time off.
So Linus is here today to explain to us why on Earth he would write a software tool which only he is smart enough to know how to use. Thanks, Linus.
Linus Torvalds – Linux’s inventor
So I have a few words of warning, which is I don’t actually do speaking very much, partly because I don’t like speaking, partly because over the last few years everybody actually wants me to talk about nebulous visions for the next century about Linux. And I’m a tech geek, so I actually prefer talking about technology. So that’s why I am not talking about the kernel, because it’s just too big to cram into a one-hour talk. Although apparently, Andrew did that two days ago.
And I’m instead talking about Git, which is the source control management system that we use for the kernel. And I’m really, really, really bad at doing slides, which means that if we actually end up following these slides, you will be bored out of your mind and the talk will probably not be very good anyway.
So I am the kind of speaker who really enjoys getting questions. And if that means that we kind of veer off in a tangent, you’ll be happier, I’ll be happier, the talk will probably be more interesting anyway. I don’t know how you do things here at the Google Talks, but I’m just saying don’t feel shy as far as I’m concerned. If your manager will shoot you, that’s your problem.
So next slide. So I want to give a few credits before I start. Credit CVS in a very, very negative way because in many ways when I designed Git, it’s the what would Jesus do? Except it’s what would CVS never, ever do kind of approach to source control management. I’ve never actually used CVS for the kernel. For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is.
But I did end up using CVS for seven years at a commercial company and I hated it with a passion. When I say I hate CVS with a passion, I have to also say that if there are any SVN users in Subversion, users in the audience, you might want to leave because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started, because the slogan for Subversion for a while was, CVS done right or something like that.
And if you start with that kind of slogan, there’s nowhere you can go. It’s like — there is no way to do CVS right. So that’s the negative kind of credit.
The positive credit is BitKeeper. And I realize that a lot of people thought there was a lot of strife over BitKeeper and that the parting was very painful in many ways. As far as I’m concerned, the parting was amicable, even though it looked very non-amical to outsiders. And BitKeeper was not only the first source control system that I ever felt was worth using at all, it was also the source control system that taught me why there’s a point to them and how you actually can do things. So Git in many ways, even though from a technical angle it is very, very different from BitKeeper, which was another design goal because I wanted to make it clear that it wasn’t a BitKeeper clone, a lot of the flows we use with Git come directly from the flows we learned from BitKeeper. And I don’t think you use BitKeeper here inside Google. As far as I know, BitKeeper is the only commercial source control management system that actually does distribution. And if you need a commercial one, that’s the one you should use, for that reason.
I’d also like to point out that I’ve been doing Git now for slightly over two years, but while I started it and I made all the initial coding and design, it’s actually been maintained by a much more pleasant person, Junio Hamano, for the last year and half, and he’s really the person who actually made it more approachable for mere mortals. Early versions of Git did require certain amount of brainpower to really wrap your mind around. It’s got much much easier since. There’s obviously the way I always do everything is I try to do everybody else to do as much as possible so I can sit back and sip my Piña Colada, so there has been a lot of other people involved, too.
That’s the credits. With those out of the way – okay, so this slide is now one day old. I didn’t actually do the slides last night because last night I was out carousing and eating Sushi, but the slides will talk about implementation of a reliable, high performance, distributed content management thing. And the keyword here is actually the “distributed” part. I will start off trying to explain why distribution is so important. If we never get past that point, I will actually be happy. If we never get to actually what Git’s implementation internally is, it’s fine.