On Wed, 24 Aug 2005, Linus Torvalds wrote: > > Basically, he had two branches, A and B, and both contained the same patch > (but _not_ the same commit). One undid it, the other did not. There's no > real way to say which one is "correct", and both cases clearly merge > perfectly, so both outcomes "patch applied" and "patch reverted" are > really equally valid.
In fact, the case that git selected ("patch applied"), is not only the one that is very fundamentally the one git will always select in this kind of situation - in some respects is actually the nicer choice of the two. While it may cause problems (ie the revert was the right thing to do), it's at least the state that is less likely to be "lost". Having a revert disappear is likely better than having a real change disappear. The reaction to the reverted code showing up again is likely "damn, won't that bug ever go away, I fixed it once already" - but at least people will see that it's fair: "it was applied twice, so let's revert it twice". In contrast, the reaction to a patch going away is likely just very confusing: you have two people applying it, but only one reverting it will revert both, while the first person who applied it may never have realized it got reverted. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html