On Mon, 29 Aug 2005, Junio C Hamano wrote:
>
> > 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.
Well, that too, but I did mention doing the same thing for stage 1, which
is the "multiple merge bases" case.
It all boils down to the same thing: we want to read in multiple trees,
and then do merges one file at a time based on the result (and the fact
that we can have multiple entries for files in the different stages
essentially just complicates "git-merge-one-file").
> 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",
Daniel pointed out that there is a real reason for stage 2 - it's used as
a special case for "matches current index". Apart from that, it's the same
as stage 3.
Stage 3 is the one we can duplicate freely. There's can be only one branch
that is special in that it matches the current index, so expanding stage 3
from one to many is clearly something where all the different trees are on
equal footing.
Same goes for stage 1 - all merge bases are conceptually equally valid,
and thus there is no reason to consider any "ordering" between them, and
you can merge any number of trees into stage 1.
So stage 0 and stage 2 are special in that they inherently have "one
special tree" that they correspond to.
Linus
-
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
