Placeholder Image

Subtitles section Play video

  • MALE SPEAKER: 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: 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.

  • 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.

  • 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.

  • 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 run, 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 design, it's actually being

  • maintained by a much more pleasant person, Junior

  • Hermano, for the last year and a half.

  • And he's really the person who actually made it more

  • approachable for mere mortals.

  • Early versions of Git did require a certain amount of

  • brainpower to really wrap your mind around.

  • It's gotten much, much easier since.

  • Obviously the way I always do everything is I try to get

  • everybody else to do as much as possible so that I can sit

  • back and sip my pina colada, so there's been a lot of other

  • people involved, too.

  • That's the credits.

  • With those out of the way.

  • So this slide is now one day old, and 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 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 implementation

  • internally is, it's fine.

  • I am not also trying to teach you how to use Git.

  • There is this thing called google.com.

  • You may have seen it.

  • It has this thing you can type things into.

  • You type Git and then you press the I'm Feeling Lucky

  • button, and you will actually get the home page.

  • The home page has tutorials, it has the user manual,

  • they're all in HTML.

  • If you actually want to learn to use Git, that's where you

  • should start, not at this talk.

  • But as mentioned, if we actually start veering off

  • topic into other tangents because of

  • questions, it's all good.

  • I already gave you kind of a heads up warning on this.

  • I use the SCM, which I consider to mean Source Code

  • Management, that is, revision control.

  • Some other people think SCM means Software Configuration

  • Management and see it as a much bigger feature, including

  • release management and stuff like that.

  • That's not what I'm talking about, although Git is clearly

  • relevant in that setting, too.

  • CVS, we already went there.

  • You can disagree with me as much as you want, but during

  • this talk, by definition anybody who disagrees is

  • stupid and ugly.

  • So keep that in mind.

  • When I'm done speaking, you can go on with their lives.

  • Right now, yes.

  • I have strong opinions and CVS users, if you actually like

  • using CVS, you shouldn't be here.

  • You should be in some mental institution somewhere else.

  • So before actually go and talk about the whole distribution

  • thing, which I think is the most important part, I'll talk

  • a bit about the background because it invariably comes up

  • because people, if they have heard about Git, a lot of the

  • things they've heard about is the background for doing it in

  • the first place.

  • One piece of background information is I really am not

  • an SCM person.

  • I have never been very

  • interested in revision control.

  • I thought it was evil until I met BitKeeper.

  • I actually credit that to some degree for why Git is so much

  • better than everything else.

  • It's because my brain did not rot from years and years of

  • thinking CVS did something sane.

  • I needed a replacement for BitKeeper.

  • The reason for that was BitKeeper is a commercial

  • product, but BitMover and Larry McVoy allowed it to be

  • used freely for open source projects, as

  • some of you may know.

  • The only restriction was you were not supposed to reverse

  • engineer it and you weren't supposed to try to create a

  • competing product.

  • And I was happy with that because, quite frankly, as far

  • as I'm concerned I do open source because I think it's

  • the only right way to do software.

  • But at the same time, I'll use the best tool for the job and,

  • quite frankly, BitKeeper was it.

  • However, not everybody agreed with me.

  • They are ugly and stupid.

  • But they cause problems and it resulted in the fact that

  • Larry and I had several telephone conversations which

  • ended up saying we'll all be much happier if we just part

  • ways and don't make this any worse.

  • So we did.

  • And I made the Linux 2.6.12-rc2 release about two

  • years ago and said, I'm not going to touch Linux until I

  • have a replacement for BitKeeper for doing source

  • code maintenance.

  • And one of the replacement options was going back to

  • tarballs and patches, but nobody

  • really liked that anymore.

  • So I actually looked at a lot of alternatives.

  • Most of them I could discard without even trying them out.

  • If you're not distributed, you're not worth using.

  • It's that simple.

  • If you perform badly, you're not worth using.

  • It's that simple.

  • And if you cannot guarantee that the stuff I put into an

  • SCM comes out exactly the same, you're not worth using.

  • Quite frankly, that pretty much took care of

  • everything out there.

  • There's a lot of SCM systems that do not guarantee that

  • what you get out of it again is the same thing you put in.

  • If you have memory corruption, if you have disk corruption,

  • you may never know.

  • The only way you'll know is you notice that there's

  • corruption in the files when you check them out.

  • The source control management system does not protect you at

  • all, and this is not even uncommon.

  • It is very, very common.

  • The performance issue, one of the things I kind of liked was

  • a system called monotone, which actually, I think there

  • was a talk at Google about them some time

  • ago, I'm not sure.

  • It had a lot of interesting ideas, but performance was so

  • horrendously bad that I tried it for a day and realized that

  • I cannot use it.

  • The end result was I decided I can write something better

  • than anything out there in two weeks, and I was right.

  • So now we get to distribution.

  • And this is the worst slide of them all, and I'm not very

  • proud of it.

  • And the problem is distribution is really, really

  • important, but when I tried to make slides about it I

  • could not do it.

  • And part of it is my obvious artistic talents, which are on

  • display for all of you, but part of it is that it's really

  • hard to explain.

  • So before you can start, I'd like to know how many people

  • are used to the notion of a truly distributed source

  • control management system?

  • Are most of you kernel developers?

  • No, OK.

  • So there were maybe 10 hands coming up.

  • Being distributed very much means that you do not have one

  • central location that keeps track of your data.

  • No single place is more important than any other

  • single place.

  • So for example, this is why I would never touch Subversion

  • with a 10 foot pole.

  • There is a massive Subversion repository, and it's where

  • everybody has to write.

  • The centralized model just doesn't work when you want to

  • be-- let's look at a few of the cases.

  • I say it's so much more than just offline work, but the