* Richard Levitte:
In message <address@hidden> on Sun, 1
May 2005 00:29:48 -0700, Nathaniel Smith <address@hidden> said:
njs> Here's another pathological case for 3-way merge:
njs> A
njs> |
njs> B
njs> / \
njs> C D
njs> Suppose that a file was added on the A->B edge, and then
removed again
njs> in B->C, while it was left alone on the B->D edge. We want
to merge
njs> C and D. Let's assume that for some reason we decide to use
A as a
njs> common ancestor. What will happen? Our file does not exist
in either
njs> A or C, so when comparing A and C 3-way merge will think that
nothing
njs> has happened. Our file _does_ exist in D, though, so when
comparing A
njs> and D, 3-way merge will decide that a file has been added.
Therefore,
njs> says 3-way merge, this file should exist in the new merged node.
njs> But, this is obviously wrong; the file was deleted between B
and C,
njs> and this delete should have caused a delete of D's copy as well.
I disagree with that conclusion. It's quite possible the removal of
the file in the B->C edge is a mistake, and that the person
leaving it
along in the B->D edge had it right. Especially in a fairly loose
network of cooperating programmers, disagreements of that kind are
bound to happen (and have happened). Others might call them "oopses"
rather than disagreements...
I think Nathaniel wanted to say that there is an implied conflict
which 3-way merge cannot detect, not that one choice is better than
the other. The argument that there is a hidden conflict which should
be flagged as such is quite convincing (and, as a result, the "zombie
changeset" term is misleading).