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

[Marc Branchaud <marcnarc@xiplink.com>]

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

I want the topic based on A so that I can merge it into other branches that
are also based on A.

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

Yes, that works just as well (at least until someone optimizes the reword
command).

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

That's a more fundamental question.  I don't feel strongly either way.  The
main advantage I see with having the option is that it codifies the process,
with documentation and a unit test to help make sure it doesn't break.  So if
nobody wants the new option, I would then like to add a unit test to ensure
that rebase's reword command doesn't get optimized (if such a test doesn't
already exist), and maybe also add a note to the revert-a-faulty-merge howto.

		M.