Re: [PATCHv2] Teach --no-ff option to 'rebase -i'.

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Mar 17, 2010, 16:19 UTC
Message-ID: <4BA1010E.8030908@viscovery.net>
In-Reply-To: <4BA0FD5B.5090408@xiplink.com>

Marc Branchaud schrieb:

Show 13 quoted lines

> Johannes Sixt wrote:
>> 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.

  $ echo $(git rev-parse M M^) >> .git/info/grafts

Show 7 quoted lines

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

You don't need --ff nor --no-ff in this case.

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

But why do you base the reworked topic on A instead of U or later?

Or why don't you just mark the first commit as r(eword) and just exit the editor; it would rewrite the commit and all subsequent ones will be rewritten as well. Never in my life would I have searched for a *option* that achieves the goal. It is such a rare situation that we don't need an option, do we?

-- Hannes