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

[Jacob Keller <jacob.keller@gmail.com>]

On Fri, Mar 2, 2018 at 4:36 AM, Phillip Wood <phillip.wood@talktalk.net> wrote:
> On 02/03/18 11:17, Phillip Wood wrote:
>>
>> On 02/03/18 01:16, Igor Djordjevic wrote:
>>>
>>> Hi Sergey,
>>>
>>> On 01/03/2018 06:39, Sergey Organov 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...? :/
>>>>>
>>>>> [...]
>>>>
>>>> Yeah, I now see it myself. I'm sorry for being lazy and not inspecting
>>>> this more carefully in the first place.
>>>
>>> No problem, that`s why we`re discussing it, and I`m glad we`re
>>> aligned now, so we can move forward :)
>>>
>>>>> So while your original proposal currently seems like it could be
>>>>> working nicely for non-interactive rebase (and might be some simpler
>>>>> interactive ones), now hitting/acknowledging its first real use
>>>>> limit, my additional quick attempt[1] just tries to aid pretty
>>>>> interesting case of complicated interactive rebase, too, where we
>>>>> might be able to do better as well, still using you original proposal
>>>>> as a base idea :)
>>>>
>>>> Yes, thank you for pushing me back to reality! :-) The work and thoughts
>>>> you are putting into solving the puzzle are greatly appreciated!
>>>
>>> You`re welcome, and I am enjoying it :)
>>>
>>>> Thinking about it overnight, I now suspect that original proposal had a
>>>> mistake in the final merge step. I think that what you did is a way to
>>>> fix it, and I want to try to figure what exactly was wrong in the
>>>> original proposal and to find simpler way of doing it right.
>>>>
>>>> The likely solution is to use original UM as a merge-base for final
>>>> 3-way merge of U1' and U2', but I'm not sure yet. Sounds pretty natural
>>>> though, as that's exactly UM from which both U1' and U2' have diverged
>>>> due to rebasing and other history editing.
>>>
>>> Yes, this might be it...! ;)
>>>
>>> To prove myself it works, I`ve assembled a pretty crazy `-s ours`
>>> merge interactive rebase scenario, and it seems this passes the test,
>>> ticking all the check boxes (I could think of) :P
>
> Hi Igor
>
>> It is interesting to think what it means to faithfully rebase a '-s
>> ours' merge.
> I should have explained that I mean is a faithful rebase one that
> adheres to the semantics of '-s ours' (i.e. ignores any changes in the
> side branch) or one that merges new changes from the side branch into
> the content of the original merge? In your example you add B4 to B. If
> M' preserves the semantics of '-s ours' then it will not contain the
> changes in B4. I think your result does (correct me if I'm wrong) so it
> is preserving the content of the original merge rather than the
> semantics of it.
>
> Best Wishes
>
> Phillip
>

I believe this was always the outline of this type of approach, as per
Sergey's original email.

We only have the content, and we don't know the semantics (nor, I
think, should we attempt to understand or figure out the semantics).

Regards,
Jake