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.