From: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date: Thu, 05 Apr 2012 16:16:54 GMT
Subject: Re: rebase -p loses amended changes
Message-ID: <CAOeW2eHHW6de1qcnajV7DLzWyiSJyh+ZpMbhQU-1WKnRuSeNhg@mail.gmail.com>
In-Reply-To: <4F7BEA9F.3060805@viscovery.net>

On Tue, Apr 3, 2012 at 11:30 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> IMO, it is a sub-optimal implementation of rebase -p that it attempts to
> redo the merge. A better strategy is to just replay the changes between
> the first parent and the merge commit, and then generate a new merge commit:
>
>   git diff-tree -p M^ M | git apply --index &&
>   git rev-parse M^2 > .git/MERGE_HEAD &&
>   git commit -c M
>
> This would side-step all the issues discussed here, no?

Maybe. How would it handle the following, though?

With this history

          .-e-.
         /     \
      .-c---d---f
     /
a---b---g

, "git rebase -p --onto g b f" produces


              .-e'.
             /     \
a---b---g---c'--d'--f'

If the merge was interactive (or was made interactive due to merge
conflicts), e'-c' (the diff between c' and e') might be very different
from e-c. Creating f' by replaying f-d on top of d' would lose any
changes done in e'-c' as compared to e-c, no?

Sorry I this has already been said or if I'm missing the point; I have
not been following the conversion completely.

Martin