On 28/02/2018 01:36, Jacob Keller 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...? :/
>
> In that case, the method won't work well at all, so I think we need a
> different approach.
>
Hmm, still rushing it, but what about adding an additional step,
something like this:
(4) ---X1---o---o---o---o---o---X2
|\ |\
| A1---A2---A3---U1 | A1'--A2'--A3'--U1'--R1
| \ |
| M |
| / |
\-B1---B2---B3---U2 \-B1'--B2'--B3'--U2'--R2
... where:
R1 = git diff U2 U2' | git apply --3way
R2 = git diff U1 U1' | git apply --3way
(this is just to explain the point, might be there is a better way to
produce Rx)
So, we still use Ux' to preserve merge commit M amendments, but also
Rx to catch any changes happening between Ux and Ux' caused by
interactive rebase commit manipulation (add/amend/drop).
Note that R*1* is produced by applying diff from U*2*' side, and vice
versa (as it`s the other side that can erroneously introduce dropped
commit changes back, like U2' in case of dropped A2').
>From here we continue as before - merging R1 and R2, then rewriting
merge commit parents to point to A3' and B3' (dropping Ux` and Rx).
This seems to be working inside my (too trivial?) test case, for
interactive adding, dropping, and amending of rebased commits,
resulting "rebased" merge containing all the added/modified/dropped
changes, plus the original merge amendment, all as expected :P
Regards, Buga
