On 06/03/18 18:12, Johannes Schindelin wrote: > Hi Phillip, > > On Tue, 6 Mar 2018, Phillip Wood wrote: > >> On 03/03/18 00:29, Igor Djordjevic wrote: >>> >>> On 02/03/2018 12:31, Phillip Wood wrote: >>>> >>>>> Thinking about it overnight, I now suspect that original proposal >>>>> had a mistake in the final merge step. I think that what you did is >>>>> a way to fix it, and I want to try to figure what exactly was wrong >>>>> in the original proposal and to find simpler way of doing it right. >>>>> >>>>> The likely solution is to use original UM as a merge-base for final >>>>> 3-way merge of U1' and U2', but I'm not sure yet. Sounds pretty >>>>> natural though, as that's exactly UM from which both U1' and U2' >>>>> have diverged due to rebasing and other history editing. >>>> >>>> Hi Sergey, I've been following this discussion from the sidelines, >>>> though I haven't had time to study all the posts in this thread in >>>> detail. I wonder if it would be helpful to think of rebasing a merge >>>> as merging the changes in the parents due to the rebase back into the >>>> original merge. So for a merge M with parents A B C that are rebased >>>> to A' B' C' the rebased merge M' would be constructed by (ignoring >>>> shell quoting issues) >>>> >>>> git checkout --detach M >>>> git merge-recursive A -- M A' >>>> tree=$(git write-tree) >>>> git merge-recursive B -- $tree B' >>>> tree=$(git write-tree) >>>> git merge-recursive C -- $tree C' >>>> tree=$(git write-tree) >>>> M'=$(git log --pretty=%B -1 M | git commit-tree -pA' -pB' -pC') >>>> >>>> This should pull in all the changes from the parents while preserving >>>> any evil conflict resolution in the original merge. It superficially >>>> reminds me of incremental merging [1] but it's so long since I looked at >>>> that I'm not sure if there are any significant similarities. >>>> >>>> [1] https://github.com/mhagger/git-imerge >>> >>> Interesting, from quick test[3], this seems to produce the same >>> result as that other test I previously provided[2], where temporary >>> commits U1' and U2' are finally merged with original M as a base :) >>> >>> Just that this looks like even more straight-forward approach...? >>> >>> The only thing I wonder of here is how would we check if the >>> "rebased" merge M' was "clean", or should we stop for user amendment? >>> With that other approach Sergey described, we have U1'==U2' to test with. >> >> I think (though I haven't rigorously proved to myself) that in the >> absence of conflicts this scheme has well defined semantics (the merges >> can be commuted), so the result should be predicable from the users >> point of view so maybe it could just offer an option to stop. > > I am not so sure that the result is independent of the order of the > merges. In other words, I am not necessarily certain that it is impossible > to concoct A,A',B,B' commits where merging B'/B before A'/A has a > different result than merging A'/A before B'/B. > > Remember, when constructing counter-examples to hypotheses, those > counter-examples do not really *have* to make sense on their own. For > example, A' could introduce *completely different* changes from A, and the > same is true for B' and B. > > I could imagine, for example, that using a ton of consecutive empty lines, > and using patches that insert something into these empty lines (and are > thusly inherently ambiguous when said set of empty lines has changed), > could even introduce a merge conflict in one order, but no conflict in the > other. Yes I should have thought of that given I've just been working on making 'add -p' more robust when there are lots of identical lines. > Even so, I think that merging in the order of the parents makes the most > sense, and that using that strategy makes sense, too, because you really > have to try hard to make it fail. > > Ciao, > Dscho >
