> > The results for the test indicate that the merge should > > succeed, but also that "a" should no longer exist. Since > > both sides renamed "a" to the same destination, we will end > > up comparing those destinations for content. > > But what about what's left? One side (the rename only), > > replaced "a" with nothing. The other side replaced it with a > > symlink. The common base must also be nothing, because any > > "a" before this was meaningless (it was totally unrelated > > content that ended up getting renamed). > > The only sensible resolution is to keep the symlink. > I agree. > We should treat structural changes and do a 3-way on that, and then > another 3-way on content changes, treating them as an independent > thing. > One side has "create 'e' out of 'a', removing 'a'" and "_create_ 'a', > that > is unrelated to the original 'a'", the other side has "create 'e' out > of > 'a', removing 'a'", so the end result should be that we do both, > i.e. "create 'e' out of 'a', removing 'a'" and "create 'a'". At the > content level, the result in 'e' may have to be decided by 3-way. The > result in 'a' should be a clean merge taken from the former "with b/c > link" branch, as this is not even a create (by the side that added a > backward compatibility symbolic link) vs a delete (by pure-rename side) > conflict. I completely agree, keeping the symlink would be the right thing to do. When I worked on the patch which added that test, my only concern was eliminating the rename/add conflict on "e" (which seemed pointless, since the content of "e" was identical in both branches). --Ken Schalk -- 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