Igor Djordjevic [off-list ref] writes:
On 27/02/2018 20:59, Igor Djordjevic wrote:
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...? :/
p.s. Looks like Johannes already elaborated on this in the meantime,
let`s see... (goes reading that other e-mail[1])
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.
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.
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).
Hi Junio,
On 28/02/2018 01:10, Junio C Hamano wrote:
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...? :/
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@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz/
[2] https://public-inbox.org/git/8829c395-fb84-2db0-9288-f7b28fa0d0d1@gmail.com/