Hi Jacob, Jacob Keller <jacob.keller@xxxxxxxxx> writes: > On Wed, Apr 18, 2018 at 9:24 PM, Sergey Organov <sorganov@xxxxxxxxx> wrote: >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> >>> Hi Phillip, >>> >>> On Fri, 13 Apr 2018, Phillip Wood wrote: >>> >>>> On 12/04/18 23:02, Johannes Schindelin wrote: >>>> > >>>> > [...] >>>> > >>>> > So: the order of the 3-way merges does matter. >>>> > >>>> > [...] >>>> >>>> Those conflicts certainly look intimidating (and the ones in your later >>>> reply with the N way merge example still look quite complicated). One >>>> option would be just to stop and have the user resolve the conflicts >>>> after each conflicting 3-way merge rather than at the end of all the >>>> merges. There are some downsides: there would need to be a way to >>>> explain to the user that this is an intermediate step (and what that >>>> step was); the code would have to do some book keeping to know where it >>>> had got to; and it would stop and prompt the user to resolve conflicts >>>> more often which could be annoying but hopefully they'd be clearer to >>>> resolve because they weren't nested. >>> >>> I thought about that. But as I pointed out: the order of the merges *does* >>> matter. Otherwise we force the user to resolve conflicts that they >>> *already* resolved during this rebase... >> >> How it's relevant to what Phillip suggested? How the order of taking 2 >> steps, A and B, affects an ability to stop after the first step? It's >> still either "A,stop,B" or "B,stop,A", depending on the chosen order. >> >> What's the _actual_ problem here, if any? >> >> -- Sergey > > I believe the order of the merges changes which ones cause conflicts, > but it's possible to generate pre-images (i.e. a set of parents to > merge) which cause conflicts regardless of which ordering we pick, so > I'm not sure there is a "best ordering". I totally agree, but this still does not address the problem of recursive conflicts, and it's this particular problem that Phillip's suggestion addresses. Just stop after _every_ conflict and let user resolve it, whatever the order is. Recursive conflicts are simply showstoppers. Whatever cleverness is invented to represent them, it will still outsmart most of the users. As for your statement, it should be clear the absolute "best ordering" simply can't exist, as merges are inherently symmetric in the DAG. One can try all orders in turn and select one that brings less conflicts though. Comparing conflicts is a problem by itself here. Recursive vs non-recursive and conflict vs no-conflict are obvious and could be the only checks adopted, all other cases being considered equal. If we do select fixed order method, or can't find the best order, the default order should simply match the natural one, first parent first. Besides, it's the change to the mainline that is most important for an actual Git merge, so letting it come first sounds most reasonable. -- Sergey
