Hi Sergey, On 02/03/2018 06:40, Sergey Organov wrote: > > > So... In comparison to original merge commit M, rebased merge commit > > M' is expected to: > > > > - Add X9, from updated "master" > > - Have A1 changed to A12, due to A12 commit amendment > > - Keep A2, rebased as A2' > > - Remove A3, due to dropped A3 commit > > - Keep amendment from original (evil) merge commit M > > - Miss B1' like M does B, due to original `-s ours` merge strategy > > - Add B2, cherry-picked as B2' into "master" > > - Add B3, cherry-picked as B3' into "A" > > - Add B4, added to "B" > > - Most important, provide safety mechanism to "fail loud", being > > aware of non-trivial things going on, allowing to stop for user > > inspection/decision > > > > > > There, I hope I didn`t miss any expectation. And, it _seems_ to work > > exactly as expected :D > > That's very nice, to the level of being even suspect! :-)
Heh, indeed :) I`m already thinking of some even more complex situations. The more use/test cases, the merrier. Like if number of merge parents (branches) gets changed during interactive rebase... > To avoid falling into euphoria though, we need to keep in mind that > "expectations" is rather vague concept, and we likely still need to stop > for user amendment unless we absolutely sure nothing surprising happens. > I.e., we better require U1'==U2' test to succeed to proceed non-stop > automatically. Besides, it will be somewhat inline with what 'rerere' > does. I totally agree, and I think whatever we come up with, we`ll always be missing some deeper context of the original merge, so U1'==U2' test is a must - if it fails, even if we didn`t get any conflicts and could otherwise proceed automatically, better stop for user sanity check. I`m still thinking if there could be a situation where test passes, but result might still be suspicious (and worth inspecting), though. Regards, Buga
