Hi Igor, Igor Djordjevic <igor.d.djordje...@gmail.com> writes:
> On 28/02/2018 21:25, Igor Djordjevic wrote: >> >> But U1' and U2' are really to be expected to stay the same in >> non-interactive rebase case only... > > Just to rephrase to "could be expected" here, meaning still not > necessarily in this case, either - I`ve just witnessed > non-interactive rebase Johannes previously described[1], merge with > `-s ours` (dropping B* patches), plus B1 cherry-picked between > X1..X2, eventually coming up with different U1' and U2', too (which > would produce a wrong end result, if continued). Even non-interactive rebase may bring arbitrary asymmetric changes on both sides of the merge, especially likely when resolving conflicts needs to take place. OTOH, interactive history editing session could have merges that we don't intend to edit at all. Overall, neither non-interactive case is in fact much simpler, nor interactive case is so much different. > But I guess this should go to the "complex history" pile, good thing > still being that diff safety check between U1' and U2' works as > expected, thus automatic merge rebase can be aborted and command > given back to the user for closer inspection. Exactly. This fact hopefully won't stop us from looking for more suitable automated handling of the general case though. It should still be our goal to reduce the number of such aborts and to suggest better merge result for amendment when we are still aborting. Your proposal hopefully is such a valuable improvement. -- Sergey
