On Fri, Mar 2, 2018 at 4:36 AM, Phillip Wood <phillip.wood@xxxxxxxxxxxx> 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
