Hi Sergey, On 28/02/2018 06:19, 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...? :/ > > I think the method will handle this nicely. That`s what I thought as well. And then I made a test. And then the test broke... Now, might be the test was flawed in the first place, but thinking about it a bit more, it does seem to make sense not to handle this case nicely :/ > When you "drop" A2, will A3' change, or stay intact? When you "drop" commit A2 from rebasing, patch (diff) A3' does stay the same - but resulting tree (snapshot) after applying it does not. By removing commit A2 from your rebase, you`re saying that changes introduced in that commit shouldn`t ever happen in the rebased tree, so trees/snapshots of all rebased commits coming after dropped A2 will have these changes missing, in comparison to trees of original commits they`re being rebased from. > 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. All true, but note what I wrote in the original message - the issue of dropping A2 is not U1, but U2, and that one doesn`t change. In this case, U1' will correctly represent U1 rebased on top of A3' (where A2 is now missing), no problem there. But on the other end, as U2 holds changes between original merge and B3 (being A1, A2, A3 and evil-merge M), it will also still hold changes introduced by original A2. Rebasing it onto B3' brings all these changes along, and once merged with U1' to produce "rebased" merge it unexpectedly introduces supposedly dropped commit A2 changes in their full glory. Yes, considering this situation a conflict, as originally proposed, by simply noticing that U1' and U2' differ, helps this to fail loudly without doing the wrong thing. But U1' and U2' are really to be expected to stay the same in non-interactive rebase case only, where it doesn`t help interactive rebase case at all if it is to fail most of the time (where U1' and U2' don`t have to be, but should be expected to possibly be different). 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 :) Regards, Buga [1] https://public-inbox.org/git/8829c395-fb84-2db0-9288-f7b28fa0d0d1@xxxxxxxxx/
