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
> 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'
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.