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

[Johannes Sixt <j.sixt@viscovery.net>]

Marc Branchaud schrieb:
> 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

> 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