Hi again, Sorry to keep talking to myself here... Jonathan Nieder wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html