Hi Jake, On Thu, 19 Apr 2018, Jacob Keller wrote: > On Wed, Apr 18, 2018 at 9:24 PM, Sergey Organov <sorganov@xxxxxxxxx> wrote: > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > >> 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, That is a correct interpretation of the example I showed. > 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". In general, there is no best ordering, you are right. There is no silver bullet. I am not satisfied with stating that and then leaving it at that. In the example I presented, you can see that there are common cases where there *is* a best ordering. In the wrong order, even if you would force the user to resolve the merge conflict in an intermediate merge (which would introduce a nightmare for the user interface, I am sure you see that), then the next merge would *again* show merge conflicts. And I, for one, am *really* certain what my decision would be when offered the two options 1) force the user to resolve merge conflicts *twice*, or 2) reorder the intermediate merges and present the user with exactly one set of merge conflicts. So it is irrelevant that there might not be a "best order" in the general case, when in the common cases quite frequently there is. It is just another example where theory disagrees with practice. Don't get me wrong: it is good to start with theory. And likewise it is simply necessary to continue from there, and put your theory to the test. And then you need to turn this into something practical. Ciao, Dscho
