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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mar 17, 2010, 18:13 UTC
Message-ID: <20100317181347.GA26376@progeny.tock>
In-Reply-To: <20100317175320.GA26124@progeny.tock>

Hi again,

Sorry to keep talking to myself here...

Jonathan Nieder wrote:

Show 12 quoted lines

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

Almost certainly bad.

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

Might be bad, might not, depending on what topic2 is about.

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

Or rather: rewrite every branch that you want to make supersede U.

Surprisingly tricky.

I prefer the “revert the faulty revert” technique because it is more transparent. If it is only possible to re-merge now because of developments that occured in topic, a simple revert would create a non-bisectable history, but Johannes’s trick (or the uglier method I described before) should work.

 git checkout master
 : >> .git/info/grafts
 cp .git/info/grafts .git/info/saved-grafts
 echo $(git rev-parse M M^) >> .git/info/grafts
 git merge topic;	# being sure to mention M in the commit message!
 mv .git/info/saved-grafts .git/info/grafts

Jonathan