On Fri, Apr 20, 2018 at 1:26 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > 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 I recall you suggested an approach of "try one way, if there are conflicts, check the other way and see if it had conflicts". And I also agree that forcing the user to resolve conflicts in the middle of the operation is a huge nightmare of a user interface, probably worse than the issues with nested merge conflicts. Thanks, Jake
