Re: Comments in read-tree about #nALT

From: Linus Torvalds <torvalds@osdl.org>
Date: Aug 27, 2005, 23:35 UTC
Message-ID: <Pine.LNX.4.58.0508271621210.3317@g5.osdl.org>
In-Reply-To: <Pine.LNX.4.63.0508271855100.23242@iabervon.org>

On Sat, 27 Aug 2005, Daniel Barkalow wrote:

> 
> What I missed was that the effect of causes_df_conflict is to give "no
> merge" for the entry, rather than giving an error overall. So I do need an
> equivalent.

Daniel, 
 I'm not 100% sure what you're trying to do, but one thing that might work 
out is to just having multiple "stage 3" entries with the same pathname.

We current use 4 stages:
 - stage 0 is "resolved"
 - stage 1 is "original"
 - stage 2 is "one branch"
 - stage 3 is "another branch"

But if we allowed duplicate entries per stage, I think we could easily just fold stage 2/3 into one stage, and just have <n> entries in stage 2. That would immediately mean that a three-way merge could be <n> way.

The only rule would be that when you add a entry to stage 2, you must always add it after any previous entry that is already in stage 2. That should be easy.

In fact, this extension might even allow us to solve the "multiple merge base" problem: we could allow multiple entries in "stage 1" too, ie one entry per merge base (and just collapse identical entries - there's no ordering involved in stage 1 entries).

So you could merge "n" trees with "m" bases, and all without really changing the current logic much at all.

Maybe I'm missing something (like what you're trying to do in the first place), but this _seems_ doable.

Of course, "git-merge-one-file" gets more interesting as a result.

			Linus