Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

From: Sergey Organov <sorganov@gmail.com>
Date: Feb 28, 2018, 05:19 UTC
Message-ID: <87606hoflx.fsf@javad.com>
In-Reply-To: <940d959d-151d-68dd-0f13-320ebad0d75b@gmail.com>

Igor Djordjevic <igor.d.djordjevic@gmail.com> writes:

Show 15 quoted lines

> On 27/02/2018 20:59, Igor Djordjevic wrote:
>> 
>> (3) ---X1---o---o---o---o---o---X2
>>        |\                       |\
>>        | A1---A2---A3---U1      | A1'--A2'--A3'--U1'
>>        |             \          |
>>        |              M         |
>>        |             /          |
>>        \-B1---B2---B3---U2      \-B1'--B2'--B3'--U2'
>> 
>
> Meh, I hope I`m rushing it now, but for example, if we had decided to 
> drop commit A2 during an interactive rebase (so losing A2' from 
> diagram above), wouldn`t U2' still introduce those changes back, once 
> U1' and U2' are merged, being incorrect/unwanted behavior...? :/

I think the method will handle this nicely.

When you "drop" A2, will A3' change, or stay intact?

If it changes, say, to A3'', the U1' will change to U1'', and the method will propagate the change automatically.

If it A3' doesn't change, then there are no changes to take.

-- Sergey