Hi Junio,
On 28/02/2018 01:10, Junio C Hamano 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...? :/
>
> As long as we are talking about rebase that allows us users to
> adjust and make changes ("rebase -i" being the prime and most
> flexible example), it is easy to imagine that A1'--A3' and B1'--B3'
> have almost no relation to their original counterparts. After all,
> mechanical merge won't be able to guess the intention of the change
> humans make, so depending on what happend during X1 and X2 that
> happend outside of these two topics, what's required to bring series
> A and B to series A' and B' can be unlimited. So from that alone,
> it should be clear that replaying difference between M and A3 (and M
> and B3) on top of U1' and U2' is hopeless as a general solution.
Yeah, I`ve encountered it in my (trivial) test case :(
> It is acceptable as long as a solution fails loudly when it does the
> wrong thing, but I do not think the apporach can produce incorrect
> result silently, as your example shows above.
Hmm, I think my example doesn`t even try to prevent failing, but it
should otherwise be perfectly capable of doing so (and doing it
loudly) - for example, it`s enough to diff U1' and U2' - if not the
same, user might want to confirm the "rebased" merge outcome, as
either something went wrong, or interactive rebase happened... or
both :) (it`s what Sergey originally explained, seeming to be a solid
safety net, though more testing would be good)
> What you _COULD_ learn from an old merge is to compute:
>
> - a trial and mechanical merge between A3 and B3; call that pre-M
>
> - diff to bring pre-M to M (call that patch evil-M); which is
> what the person who made M did to resolve the textual and
> semantic conflicts necessary to merge these two topics.
>
> Then when merging A3' and B3', you could try to mechanically merge
> them (call that pre-M'), and apply evil-M, which may apply cleanly
> on top of pre-M', or it may not. When there aren't so huge a
> difference between series A and A' (and series B and B'), the result
> would probably be a moral equivalent of Sergay's "replay" (so this
> approach will also silently produce a wrong result without human
> supervision). One edge the evil-M approach has over Sergey's "dual
> cherry pick" is that it separates and highlights non-mechanical
> conflict resolution out of mechanical merges in a human readable
> form (i.e. the patch evil-M).
This seems to be what Johannes wrote about[1], too, but also
something I think would be good to avoid, if possible, not
complicating it too much :P
Maybe something like that latest thought[2] could help, using
additional R1 and R2 commits to handle interactive rebase
additions/amendments/drops, on top of U1' and U2'? Yeah, and
that`s not complicating it... ;) :D
Regards, Buga
[1] https://public-inbox.org/git/nycvar.QRO.7.76.6.1802272330290.56@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
[2] https://public-inbox.org/git/8829c395-fb84-2db0-9288-f7b28fa0d0d1@xxxxxxxxx/
