Hi Sergey, On 28/02/2018 07:14, Sergey Organov 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-f7b28fa0d0d1@xxxxxxxxx/ > > > > 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) > > > > ... > > > > 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. I agree, and as I really liked "the feeling" of the original approach you described, it felt bad to (presumably) see it failing in what doesn`t seem to be neither too complex nor rare situation of dropping a commit during an interactive rebase, thus motivation to try to improve it, if possible, wasn`t lacking :) Eh, might be I`m just naively ignorant at the moment as well, but I`m trying to work my way through it... ;) Regards, Buga
