From: Johannes Sixt <j.sixt@viscovery.net>
Date: Wed, 04 Apr 2012 06:30:55 GMT
Subject: Re: rebase -p loses amended changes
Message-ID: <4F7BEA9F.3060805@viscovery.net>
In-Reply-To: <CABURp0pnXvnT2=fDJXk-yiGctsJBHiNGSCOZiT4Vo74woi0Zxg@mail.gmail.com>

Am 4/4/2012 0:09, schrieb Phil Hord:
> On Tue, Apr 3, 2012 at 5:43 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
>> Suppose you have a merge of a A and B that produces M, which is then
>> amended as M'.
>>
>> During rebase, you redo the merge A and B. If there are no conflicts,
>> then compare M with M' to produce D. You now have enough information
>> to reproduce the amended commit M' during a rebase (merge Ar and,Br
>> then apply D).
> 
> How does M' know it is an amended version of M?  When you amended the
> commit M you threw away this linkage.
> 
> If you created M' as a new commit D instead, then I would agree that
> you have enough information to do what you seek.  In fact, I'm pretty
> sure git does this already.

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?

-- Hannes