Re: Current state / standard advice for rebasing merges without information loss/re-entry?

[Martin von Zweigbergk <martinvonz@gmail.com>]

On Tue, Apr 19, 2022 at 2:50 AM Tao Klerks <tao@klerks.biz> wrote:
>
> On Tue, Apr 19, 2022 at 6:25 AM Martin von Zweigbergk
> <martinvonz@gmail.com> wrote:
> >
> > Consider this case:
> >
> >   X
> >  /
> > A---B---C
> >  \       \
> >   D---E---F
> >
> > If you now want to rebase E onto X, and then F onto E' and C, then
> > Elijah's suggestion (and what my VCS does) will work correctly. If I
> > understood Sergey's proposal, on the other hand, the utility merge
> > would bring in the changes from D as well. Or, put another way, that
> > algorithm is only useful for rebasing "internal" merges, where the
> > merge commit is being rebased along with both (all of) its legs
> > (again, if I understood it correctly).
> >
>
> FWIW, I don't believe this to be the case. If you rebase E onto X, the
> way the "D side" of the merge will be resolved, on X, will be as a
> combination of "Addition of X" and "Removal of D" onto the previous E
> commit state. The secret sauce in Sergey's approach is the application
> of a patch representing the "inverted change" to the "D arm" of the
> merge base in the original merge vs the "new D arm" (which  happens to
> no longer contain D and have X instead - I just have no better way to
> refer to it).

I see, it applies a reversed D onto E before creating the utility
merges. That makes sense.

> I haven't understood or explored Elijah's suggestion (or your
> implementation), but based on your description, it sounds like they
> end up being equivalent in result, but maybe present any conflicts
> differently (as a different patch applying to a different base). I
> expect cleanly rebased merges to come out the same, and the same
> situations/scenarios to lead to clean merges vs conflicts, but the
> presentation of conflicts to likely look different.

Yes, pretty much. I expect there would be some minor differences but I
can't think of an example.