Re: Comments in read-tree about #nALT

[Junio C Hamano <junkio@cox.net>]

Linus Torvalds <torvalds@osdl.org> writes:

> 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.

My understanding is that he is enhancing the current three-way
merge 'read-tree -m O A B' "we are at A and have come from O; we
would like to apply changes made by somebody who went from O to
A" to 'read-tree -m O1,O2,O3,... A B' to mean "any of the O_n
are merge-base candidates".  I think having multiple "stage 1"
is useful for what Daniel is doing.

> 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.

I suspect you are solving a different problem here --- an
Octopus.

But I agree that the current way of doing things in stage 2 and
stage 3 is special casing two head merges from an Octopus, and
there might not be a fundamental reason for doing so.  Folding
the current stage 2 and 3 into a single "merge target stage",
treating current stage 1 as "merge base stage", and allowing
duplicate entries in both stages might turn out to make more
sense.  I suspect this would break a lot of tools initially, but
that is part of the process of making progress.

> 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.

The same rule should apply to multiple stage 1 entries to
represent multiple candidate merge bases.