On Thu, 18 Dec 2008, Alan wrote: > > So what is the recommended way to undo mistaken merges caught after the > fact that will not fubar later merges? Oh, I suspect reverting is the right thing, it's just that then you need to remember to revert the revert if you intend to merge that branch again later. So reverting a merge isn't _wrong_ per se. It's just that you need to be aware of the consequences, and if it becomes a common situation, you have a problem in your usage patterns. Btw, even with non-merge commits, "revert" can have interesting effects exactly because it doesn't change history. For example, let's say that you had a history like this, with two branches: --> a --> b --> c --> d | +-> e --> !a where the second branch reverts 'a', but the first one does not. What happens when you merge the two branches? Is the revert sticky? In this case, yes, a merge will cause the revert to stick. But what happens if you had --> a --> b --> c --> d | +-> e --> f --> !e and 'b' and 'e' were the same patch (just applied in two different branches), and '!e' reverts that patch in the second branch. What happens to 'b' when you merge? Would you expect for 'b' to go away, since the revert undid the same data in the second branch? In that second case, the revert of 'e' will basically make git act as if 'e' didn't happen at all in the second branch, and so when you merge them, 'b' _will_ exist in the end result, so now the revert didn't "take". All of this is very self-consistent (it's a very direct result of how merges work and how revert works), but I'm just bringing these things up as examples of how 'revert' is not a totally trivial matter. You'll always find cases where you might have wished that it had acted differently when you merge things. Linus -- 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
