Re: [PATCH] [RFD] Add repoid identifier to commit

From: Jan Harkes <jaharkes@cs.cmu.edu>
Date: May 12, 2005, 16:20 UTC
Message-ID: <20050512162023.GA14010@delft.aura.cs.cmu.edu>
In-Reply-To: <2cfc403205051208506249c9aa@mail.gmail.com>

On Fri, May 13, 2005 at 01:50:50AM +1000, Jon Seymour wrote:

Show 5 quoted lines

> On 5/12/05, Jan Harkes <jaharkes@cs.cmu.edu> wrote:
> > On Thu, May 12, 2005 at 01:43:50PM +0200, Thomas Gleixner wrote:
> > ....
> > Your examples break if you consider additional merges where M syncs up a
> > couple of times (f.i. at Rn-2) before M is merged back into R.

...

Show 14 quoted lines

> If committers always follow the convention that their previous local
> commit is nominated as the first (local) parent in the commit and
> commits from foreign repositories are listed after the first parent,
> can the chain of "local" parents be an effective proxy for repoid?
> 
> Consider first a graph where there are no more than 2 parents in a merge
> 
> Ln
> |     \
> Ln-1  Fn
> |         |
> Ln-2  Fn-1
> |       /
> Ln-3

It breaks when Fn was a pull from Ln-1, and Ln was a fast-forward to Fn. Now the first parent is going to be Fn-1 and the history of the local repository after the fast forward warps to

    Fn (== Ln)
    Ln-1
    Ln-2
    Fn-1
    Ln-3

And adding repoids doesn't help a bit. However if the local repo kept a history of what the user has seen previously, it can be linearized consistently. The history file would contain Ln-3...Ln-1 before the fast-forward and would add Fn-1,Fn. We would end up with a history that looks like,

    Fn (== Ln)
    Fn-1
    Ln-1
    Ln-2
    Ln-3

Which I believe is exactly what Thomas wants to see in this case. I don't see how repoid's can be useful for this. It is a porcelain thing where you need to track what you have seen before. Anything else doesn't matter because most permutations of the history are perfectly valid since the Fn and Ln changes in reality occured in parallel and as a result can be arbitrarily interleaved.

In fact anyone else who branched at Ln-3 and merges again at Ln doesn't really care in what order changes in the F and L branches occurred, only that all modifications are included.

Jan