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

On Fri, Mar 2, 2018 at 4:36 AM, Phillip Wood [off-list ref] wrote:

On 02/03/18 11:17, Phillip Wood wrote:

quoted

On 02/03/18 01:16, Igor Djordjevic wrote:

quoted

Hi Sergey,

On 01/03/2018 06:39, Sergey Organov wrote:

quoted

quoted

quoted

(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 :)

quoted

quoted

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 :)

quoted

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

quoted

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