Johannes Schindelin <johannes.schinde...@gmx.de> 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
