On Tue, Apr 3, 2012 at 11:30 PM, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html