Hi Phillip, Phillip Wood <phillip.wood@xxxxxxxxxxxx> writes: [...] > 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') I wonder if it's OK to exchange the order of heads in the first merge (also dropped C for brevity): git checkout --detach A' git merge-recursive A -- A' M tree=$(git write-tree) git merge-recursive B -- $tree B' tree=$(git write-tree) M'=$(git log --pretty=%B -1 M | git commit-tree -pA' -pB') If so, don't the first 2 lines now read: "rebase (first parent of) M on top of A'"? If so, then it could be implemented so that it reduces back to regular rebase of non-merges when applied to a single-parent commit, similar to the method in the RFC, striking out one of advantages of the RFC. -- Sergey
