Johannes Sixt wrote: > Jonathan Nieder schrieb: >> If I am understanding properly, your idea is that this would be used on >> a branch after “unmerging” it from master: >> >> B --- C --- D [topic] >> / \ >> A --- ... --- M ... --- U [master] >> >> Here M is a merge commit and U a commit reverting the change from M^ >> to M. > > If I were to re-merge topic into master a second time after this > situation, I would install a temporary graft that removes the second > parent of M and repeat the merge. After the graft is removed, the history > would look like this: > > B --- C --- D --------------. [topic] > / \ \ > A --- ... --- M ... --- U ... N [master] > > Are there any downsides? I don't know - I haven't thought it through. I'm not sure I follow how to create that graft. But the original point (which I hadn't made clear) is that at least one of the topic's commits needs to change in some substantial way. So it's not just a straight re-merge but a new take on the topic. Consider that if the topic's first commit (B) needed to be rewritten then the repaired topic would contain only new commits and it could be merged into master without reverting the first merge's reversion. What "rebase -i --no-ff" does is allow you to ensure that this will always be the case, even if you don't actually need to change the topic's first commit. M. -- 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