On Tue, Apr 19, 2022 at 6:25 AM Martin von Zweigbergk <martinvonz@xxxxxxxxx> 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 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. That said, I haven't tested them both, I was just hoping for a "current state of existing merge information reuse for merge-rebasing users" summary, and it doesn't look like there's one available so far.
