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

From: Sergey Organov <sorganov@gmail.com>
Date: Mar 13, 2018, 16:10 UTC
Message-ID: <877eqgardi.fsf@javad.com>
In-Reply-To: <6c8749ca-ec5d-b4b7-f1a0-50d9ad2949a5@talktalk.net>

Hi Phillip,

Phillip Wood <phillip.wood@talktalk.net> writes:

[...]

Show 16 quoted lines

> 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