Re: merge time

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 30, 2007, 03:06 UTC
Message-ID: <alpine.LFD.0.999.0707292000190.4161@woody.linux-foundation.org>
In-Reply-To: <498048.62681.qm@web51002.mail.re2.yahoo.com>

On Sun, 29 Jul 2007, Matthew L Foster wrote:

Show 9 quoted lines

> 
> --- Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > The fact is, distributed history isn't one-dimensional. You *cannot* 
> > linearize it as some one-dimensional time. Impossible. Any system that 
> > tries is broken. 
> 
> I don't want distributed history, I want what local time changes were 
> merged locally.

The point is, there is no "locally".

Do you mean locally on my machine? That's actually *different* from the locally on the public machines, and no, I wouldn't give you that information anyway (since that information would include the mistakes that I fixed up ;)

And in fact, even on the public machines, the "locally" would be different depending on things like mirroring delays, although that is currently hidden by the fact that kernel.org uses rsync for mirroring rather than using git natively.

So in theory, we could pick one particular public kernel.org machine, and use the times as _that_ machine sees it, but the fact is, that isn't how git works. No normal git command will ever show you such a senseless ordering.

I suspect that the closest you could get to what you want would be to actually run git-cvsserver on kernel.org to export the git data as "CVS" data, and then you could use a CVS client that gets a linearized model of history. That is, afaik, the only way to give you what you want.

And quite frankly, I'd never ask the kernel.org maintainers to do something that perverse. You could ask them, and maybe they would do so out of some really perverse self-destructive death-wish, but quite frankly, you'd probably be better off setting up such a git->CVS gateway on some local machine yourself.

			Linus