Am 4/5/2012 18:16, schrieb Martin von Zweigbergk:
> 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?
If I understand correctly, rebase -p is not intended to move branchy
history to a new fork point (that would be the task of the still
hypothetical generic sequencer). Its purpose is only to keep the merges of
other "unrelated" topics, e.g.:
...--o--o <- bugfix topic (needed by my-topic)
\
x--y--M--z <- my-topic
/
--A--o--o--B <- master
to be turned into
...--o--o--------. <- bugfix topic (needed by my-topic)
\
x'-y'-M'-z' <- my-topic
/
--A--o--o--B <- master
-- Hannes
--
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