Here's the approach I take to backout a merge with a bogus topic branch. I use this in a large team environment where backtracking the shared integration branch is simply not an option. Suppose a topic branch 'topic' was merged with master to produce a merge and then it was decided that topic was a little half-baked e.g. $> git merge topic #1 $> git tag M $> git checkout -b deliver-topic M^2 $> git diff --full-index M M^1 | git apply --index # should work if #1 did not produce a conflict $> git git commit -m "backout premature delivery of topic" $> git checkout master $> git merge deliver-topic # backouts changes contributed by #1 This assumes that neither the original merge with bogus or the merge with deliver-topic produce any conflicts. Then, suppose I fix the original problem with the topic branch by making additional commits to the original topic branch that fix the problem. I then revert the revert on the deliver-topic branch $> git checkout deliver-topic $> git revert # revert the backout to restore the deliver-topic to the same state as the original topic $> git merge topic # this is the fixed topic $> git checkout master $> git merge deliver-topic The nice thing about using a separate delivery branch to manage the backouts of prematurely merged topics is that the topic branch itself stays clean. All the revert and apply logic is confined to a delivery branch which can be forgotten about once the history moves on. Yes, the integration branch itself looks a little messy, but integration branches tend to a look a little messy anyway. jon. -- 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