Re: Comments in read-tree about #nALT

From: Junio C Hamano <junkio@cox.net>
Date: Aug 30, 2005, 00:42 UTC
Message-ID: <7vr7cc6yrg.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.58.0508271621210.3317@g5.osdl.org>

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.