Re: Comments in read-tree about #nALT

From: Linus Torvalds <torvalds@osdl.org>
Date: Aug 30, 2005, 00:58 UTC
Message-ID: <Pine.LNX.4.58.0508291751200.3243@g5.osdl.org>
In-Reply-To: <7vr7cc6yrg.fsf@assigned-by-dhcp.cox.net>

On Mon, 29 Aug 2005, Junio C Hamano wrote:

Show 7 quoted lines

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