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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mar 17, 2010, 17:53 UTC
Message-ID: <20100317175320.GA26124@progeny.tock>
In-Reply-To: <4BA0FBC7.3080305@xiplink.com>

Marc Branchaud wrote:

Show 7 quoted lines

> 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