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
