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

[Jonathan Nieder <jrnieder@gmail.com>]

Marc Branchaud wrote:

> If the re-cast topic1 doesn't rewrite those commits, then the merge will
> simply succeed because the code is already identical in both branches.
> 
> But if topic1 does rewrite those commits then there'll be a conflict.  IMO
> that's correct, because with the merging of topic2 the code in master really
> did diverge in a relevant way from what's in topic1, so that conflict should
> get resolved in the normal way.

Sorry, I did not think it through all the way.  Here is an example of
what I meant by trouble.  Suppose you have re-cast topic using
rebase --no-ff:

   B' --- C' --- D' [topic]
  /
 | B --- C --- D         F [topic2]
 |/             \       /
 A ---  ...  --- M --- E ... --- U [master]

topic represents a new feature that was merged prematurely and then
reverted, and topic2 represents some helpful new plumbing.
(introduction of a few functions, maybe).

To take advantage of the changes from F, someone merges topic2 into
topic and builds on it:

                    .. X --- Y [topic]
                   /  /
   B' --- C' --- D'  F [topic2]
  /                 /
 A -- ... -- M --- E ... --- U [master]

Now someone decides it is time to merge topic into master.  The
merge-base for Y and U is E, and the result is a that the changes from
topic are reverted.

What I had missed: it would be just as dangerous to simply merge topic2
directly.  Merging ‘master’ into ‘topic’ does nothing to prevent that.

The new advice: when using rebase --no-ff this way, be sure to rewrite
_every_ branch that includes those commits but doesn’t include U.

Jonathan