Hi Sergey,
On 13/03/2018 17:10, Sergey Organov wrote:
>
> > 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):
It should be, being "left" or "right" hand side ("theirs" or "ours")
of the three-way merge shouldn`t matter, they`re still both equally
compared to the merge-base.
> 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'"?
Hmm, lol, yes...? :) So basically, this:
(1) git checkout --detach M
git merge-recursive A -- M A'
tree=$(git write-tree)
...
... is equivalent to this:
(2) git checkout --detach A'
git merge-recursive A -- A' M
tree=$(git write-tree)
...
..., being equivalent to this:
(3) git checkout --detach A'
git cherry-pick -m 1 M
tree=$(git write-tree)
...
..., where in all three cases that `$tree` is equivalent to U1' we
discussed about so much already :)
I tested it like this as well, slightly modifying previously sent out
script (like this one[1]), and it still seems to be working ;) Nice!
> 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.
I guess so, but I think it now boils down only to what one finds
easier to reason about even more.
I`m just glad we got to U1' from this perspective as well, hopefully
adding even more faith in the overall concept, being beaten from both
ends and dropping out to be the same (minus minor implementation details).
Regards, Buga
[1] https://public-inbox.org/git/872944c4-ca97-9f55-a424-86d1e3299a22@xxxxxxxxx/
