Re: rebase -p loses amended changes

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Apr 10, 2012, 07:14 UTC
Message-ID: <4F83DDCE.1040000@viscovery.net>
In-Reply-To: <CAOeW2eHHW6de1qcnajV7DLzWyiSJyh+ZpMbhQU-1WKnRuSeNhg@mail.gmail.com>

Am 4/5/2012 18:16, schrieb Martin von Zweigbergk:

Show 32 quoted lines

> 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?

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