Re: git-rev-list in local commit order

From: Linus Torvalds <torvalds@osdl.org>
Date: May 17, 2005, 15:43 UTC
Message-ID: <Pine.LNX.4.58.0505170833330.18337@ppc970.osdl.org>
In-Reply-To: <1116323520.17296.12.camel@tglx.tec.linutronix.de>

On Tue, 17 May 2005, Thomas Gleixner wrote:

> 
> What you blow away is a work space. But at the end you push the result
> of whatever work space you kept into a public available repository. Also
> BK stores a somewhat hidden repository (not workspace) id.

No.

The public repo is secondary. Really. It has no meaning. The only thing that matters is what you call "workspace".

> My idea of repository id was not the notion of workspace seperation. I
> dont care in which directory and on which machine you or who ever
> commits a line of code. I care where the change appears in a public
> repository, which is unique.

You seem to think that the repository on master.kernel.org is more important than the one on my private machine, and you're _wrong_.

It's the _private_ repositories that are the important ones. The public ones are a communication channel, nothing more. They have no importance on their own.

I've blown the public one away several times. With BK, we've had disk corruption on kernel.org, we've had break-ins on bkbits.net, and we've had repository corruption due to people editing the SCCS files by hand. Any number of silly problems, in other words. The result? Blow the public tree away, restore it from one of the private ones from a machine that you trust.

I _never_ look at my public tree. I literally have a small script called "push-all" in my git repositories, and it does:

	#!/bin/sh
	echo master.kernel.org:
	rsync -av --delete --exclude-from=.exclude .git/ master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
	...

ie it just pushes my stuff to a few other places.

In other words, the public stuff is the _slave_. It has no meaning. The only important one is the one that the _developer_ works on.

Of course, this is not to say that everybody needs to take my approach. The nice thing about distributed systems is that a centralized system is just a trivial special case of them, so somebody else, who uses git as if it were CVS, could say "repo xxxx at git-master:/pub/git-root/project is the 'main' repository, and all the workspaces are just temporary workspaces".

But from a git _design_ point (and from a kernel usage point), the belief that a "workspace" is somehow less important than a "central repository" is just very very very wrong. Each workspace is it's own repository, and it's the _local_ ones that matter, not some "central repository".

		Linus