On 05/03/18 05:00, Sergey Organov wrote: > Hi Plillip and Igor, > > Igor Djordjevic <igor.d.djordje...@gmail.com> writes: >> Hi Phillip, >> >> 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 :) > > Looks like sound approach and it's interesting if these 2 methods do in > fact always bring the same result. Because if we look at the (now fixed) > original approach closely, it also just gathers the changes in merge > parents into U1' and U2', then merges the changes back into the original > M (=U1=U2=UM). > > Overall, this one looks like another implementation of essentially the > same method and confirms that we all have the right thought direction > here. >
Yes, I think they are doing the same thing. If there are no conflicts then U1' is the should as "git merge-recursive A -- M A'". My patch algebra isn't very good, but I think one ought to be able to show that in the absence of conflicts the two approaches are equivalent. >> >> 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. > > That's an advantage of the original, yes. I wonder if just having a predicable result rather than forcing the rebase to stop if the user just squashes a fixup commit into a topic branch that is the parent of a merge might be more convenient in practice. Best Wishes Phillip > -- Sergey >
