Re: git-rev-list in local commit order

From: Jon Seymour <jon.seymour@gmail.com>
Date: May 18, 2005, 05:16 UTC
Message-ID: <2cfc403205051722163296144@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.58.0505171035570.18337@ppc970.osdl.org>

On 5/18/05, Linus Torvalds <torvalds@osdl.org> wrote:

Show 33 quoted lines

> 
> 
> On Tue, 17 May 2005, Thomas Gleixner wrote:
> >
> > 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.

Earlier in a related thread, I argued that what everyone else has been calling a repo-id is actually a workspace id. Your GIT_COMMITER_EMAIL idea would have the same practical effect as a separate workspace id, though it does pollute the interpretation of the e-mail id's since they are no longer pure e-mail id's...

Would you be amenable to a patch that allowed tools to put attributes of the form:

   x-"some-attribute" (' ' [^\0]*)+ '\0'

into a commit header?

If, over time, x-"some-attribute" became unversially accepted as useful, a new release of git could bless it as official and the 'x-' prefix could be dropped.

In the meantime, tools could experiment with additional commit markers as they see fit without affecting the interoperability of other tools which use only the blessed markers.

Of course, a constraint on the semantics of an x-* attribute would ideally be that it's value must be fixed for all time once the commit happens since there is no way to change it without creating a new commit.

jon.