Igor Djordjevic <igor.d.djordje...@gmail.com> writes: > On 28/02/2018 03:12, Igor Djordjevic wrote: >> >> Would additional step as suggested in [1] (using R1 and R2 to "catch" >> interactive rebase additions/amendments/drops, on top of U1' and >> U2'), make more sense (or provide an additional clue, at least)? >> >> [1] >> https://public-inbox.org/git/8829c395-fb84-2db0-9288-f7b28fa0d...@gmail.com/ > > Heh, no sleeping tonight :P > > Anyway, from (yet another) ad hoc test, additional step mentioned in > [1] above seems to handle this case, too (merge with `-s ours` > dropping B* patches, plus B1 cherry-picked between X1..X2): > > On 28/02/2018 00:27, Johannes Schindelin wrote: >> >> - One of the promises was that the new way would also handle merge >> strategies other than recursive. What would happen, for example, if M >> was generated using `-s ours` (read: dropping the B* patches' changes) >> and if B1 had been cherry-picked into the history between X1..X2? >> >> Reverting R would obviously revert those B1 changes, even if B1' would >> obviously not even be part of the rebased history! >> >> Yes, I agree that this `-s ours` example is quite concocted, but the point >> of this example is not how plausible it is, but how easy it is to come up >> with a scenario where this design to "rebase merge commits" results in >> very, very unwanted behavior. > > And not just that - it worked with additional interactive rebase > adding, amending and removing commits, on top of all this still > preserving original `-s ours` merge commit evil-merge amendment, too, > all as expected (or so it seems) :P
Great! I do believe that once we start from some sensible approach, many kinds of improvements are possible. I'll definitely need to take close look at what you came up with, thanks! I'd like to say though that nobody should expect miracles from automated rebasing of merges when we get to complex history editing. It will need to retreat to manual merge, sooner or later. -- Sergey
