Linus Torvalds <[EMAIL PROTECTED]> writes:
> 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
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html