From: Marc Branchaud <marcnarc@xiplink.com>
Date: Wed, 17 Mar 2010 16:03:39 GMT
Subject: Re: [PATCHv2] Teach --no-ff option to 'rebase -i'.
Message-ID: <4BA0FD5B.5090408@xiplink.com>
In-Reply-To: <4BA07DC7.9070502@viscovery.net>

Johannes Sixt wrote:
> Jonathan Nieder schrieb:
>> If I am understanding properly, your idea is that this would be used on
>> a branch after “unmerging” it from master:
>>
>>     B --- C --- D [topic]
>>   /              \
>>  A ---  ...   --- M ... --- U [master]
>>
>> Here M is a merge commit and U a commit reverting the change from M^
>> to M.
> 
> If I were to re-merge topic into master a second time after this
> situation, I would install a temporary graft that removes the second
> parent of M and repeat the merge. After the graft is removed, the history
> would look like this:
> 
>      B --- C --- D --------------.   [topic]
>    /              \               \
>   A ---  ...   --- M ... --- U ... N [master]
> 
> Are there any downsides? I don't know - I haven't thought it through.

I'm not sure I follow how to create that graft.

But the original point (which I hadn't made clear) is that at least one of
the topic's commits needs to change in some substantial way.  So it's not
just a straight re-merge but a new take on the topic.

Consider that if the topic's first commit (B) needed to be rewritten then the
repaired topic would contain only new commits and it could be merged into
master without reverting the first merge's reversion.

What "rebase -i --no-ff" does is allow you to ensure that this will always be
the case, even if you don't actually need to change the topic's first commit.

		M.