On Wed, 24 Aug 2005, Junio C Hamano wrote:
>
> This does not have much to do with which common ancestor
> merge-base chooses. Sorry, I am not sure what is the right way
> to resolve this offhand.
I think git did the "right thing", it just happened to be the thing that
Tony didn't want. Which makes it the "wrong thing", of course, but from a
purely technical standpoint, I don't think there's anything really wrong
with the merge.
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.
Now, if the shared patch hadn't been a patch, but a shared _commit_, then
the thing would have been unambiguous - the shared commit would have been
the merge point, and the revert would have clearly undone that shared
commit.
What does this all mean? It just means that merging doesn't necessarily
even _have_ "one right answer". Automatic merges can be dangerous. The git
"global three-way" merge (global because it bases it's original state on
_global_ history, rather than local one) is about as safe as it gets (*),
but even it can have these ambigious cases that it resolves automatically,
and not the way you wanted it to.
Linus
(*) "safe as it gets" of course also means "potentially really annoying",
since it tends to require manual fixups for any even possibly half-way
ambiguous case.
-
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
