On Wed, Apr 18, 2018 at 9:24 PM, Sergey Organov <sorga...@gmail.com> wrote: > 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
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". Thanks, Jake
