Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Buga,

Igor Djordjevic <igor.d.djordjevic@gmail.com> writes:

Exactly, and thanks for noticing that it's actually U1', that happens to soon become rather handy, see below.

Very nice of you, thanks!

Yet another outcome of this transformation is that the fist step is now free to (and probably should) utilize all the options (-s, -X, etc.) that usual rebase has:

git-rebase-first-parent --onto A' M tree=$(git write-tree)

where 'git-rebase-first-parent' is whatever machinery is currently being used to rebase simple non-merge commit.

[

Moreover, Phillip's method could further be transformed to what is in RFC, not that I think it should, see below. Just for the sake of completeness though, here is the essential missing transformation that makes Phillip's method symmetric, after which it becomes true special case of the RFC with particular rebase-first-parent implementation:

git checkout --detach A' git merge-recursive A -- A' M tree_U1'=$(git write-tree) git checkout --detach B' git merge-recursive B -- B' M tree_U2'=$(git write-tree) git merge-recursive M -- $tree_U1' $tree_U2' tree=$(git write-tree) M'=$(git log --pretty=%B -1 M | git commit-tree -pA' -pB')

]

I actually think there is more to it. It's incremental asymmetric nature of the Phillip's approach that I now find rather appealing and worth to be used in practice.

While the RFC approach, being entirely symmetric, is nice from the POV of theory and reasoning, yet simple to implement, the actual user interface of Git is inherently asymmetric with respect to merges (one merges side-branch(es) to mainline), so asymmetric approach of the Phillip's method should give smoother user experience, even if only because of 1 less merge.

There are still 2 issues about the implementation that need to be discussed though:

1. Still inverted order of the second merge compared to RFC.

It'd be simple to "fix" again, except I'm not sure it'd be better, and as there is no existing experiences with this step to follow, it probably should be left as in the original, where it means "merge the changes made in B' (w.r.t B) into our intermediate version of the resulting merge".

The original Phillip's version seems to better fit the asymmetry between mainline and side-branch handling.

The actual difference will be only in the order of ours vs theirs in conflicts though, and thus it's not that critical.

2. The U1' == U2' consistency check in RFC that I still think is worth
to be implemented.

In application to the method being discussed, we only need the check if the final merge went without conflicts, so the user was not already involved, and the check itself is then pretty simple:

 "proceed without stop only if $tree = $tree_U1'"

Its equivalence to the U1' == U2' test in the RFC follows from the fact that if M' is non-conflicting merge of U1' and U2', then M' == U1' if and only if U2' == U1'.

Finally, here is a sketch of the implementation that I'd suggest to use:

git-rebase-first-parent --onto A' M
tree_U1'=$(git write-tree)
git merge-recursive B -- $tree_U1' B'
tree=$(git write-tree)
M'=$(git log --pretty=%B -1 M | git commit-tree -pA' -pB')
[ $conflicted_last_merge = "yes" ] ||
  trees-match $tree_U1' $tree || 
  stop-for-user-amendment

where 'git-rebase-first-parent' denotes whatever machinery is currently being used to rebase simple non-merge commit. Handy approximation of which for stand-alone scripting is:

git checkout --detach A' && git cherry-pick -m 1 M

[As an interesting note, observe how, after all, that original Johannes Sixt's idea of rebasing of merge commit by cherry-picking its first parent is back there.]

-- Sergey