Linus Torvalds <[EMAIL PROTECTED]> 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. - 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
