Re: git-rev-list in local commit order

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

On Tue, 17 May 2005, Thomas Gleixner wrote:

Show 17 quoted lines

>
> On Tue, 2005-05-17 at 08:43 -0700, Linus Torvalds wrote:
> > > 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_.
> 
> For me yes, as I have no access to your private ones and I can only rely
> on the integrity of the public accessible ones.
> 
> For the individual developer the private workspaces are surely more
> important. I never doubted that, but I do not care whether you use one
> or ten workspaces and which one of them you blow away or use for
> updating of master.kernel.org.

But how would you track "repositoryness", when the repository you care about has absolutely nothing to do with the repositories that any of the developers who created it in the first place care about?

See the problem? You can't. You seem to want to track information that simply does not _exist_.

Put another way: the repository ID of the eventual public "target" repository only becomes available once the information has been pushed there, not before. So a "commit" cannot contain that information, because at commit time, you fundamentally cannot know what the eventual public repository (if any) will be.

So the public repo really is nothing but a shadow of the real work, and the only reliable ordering you can do will have to depend on local information (ie things like the committer "email" value).

Now, what you _can_ do (and what the snapshot mechanism and the commit mailing list scripts do) is to create a "publicly visible timeline" thing, ie you can at regular intervals generate a snapshot of "what is the state of public repo X" and you'll get a "local commit ordering" from that.

But that local commit ordering will fundamentally depend on exactly when and how often you do the snapshotting and when I (or somebody else) happened to push to that public repo, so it will inevitably be something you can never re-create later from just the final repository contents. IOW, it's not something that "git-rev-list" can re-create - the only way to recreate it is literally to build up a separate list of "what was the head commit at time X" outside of the repository.

		Linus