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