On Tue, Apr 19, 2022 at 2:50 AM Tao Klerks <tao@xxxxxxxxxx> wrote: > > 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 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.
