On Fri, Mar 25, 2011 at 07:12:25AM -0400, Jeff King wrote: > It passes my test, and it doesn't break anything in t/. Yay. > > There's one other call to remove_file in process_renames. It's for the > case that both sides renamed the same file to the same destination. I > think there we need to actually compare the two sides. If only one side > still has something at the source path, then we can take that side > (since the other side renamed away the file). But if they both have it > (i.e., they both installed a replacement), then we need to do the usual > 3-way merge on that replacement. I'm not sure if we'd have to do that > ourselves, or if we can just punt and the rest of the merge machinery > will handle the entry. I'll have to write some tests, I think. OK, I figured it out. I was thrown off by test failures in t3030, but I think that test is actually wrong; it documents what happens, but not really what we _want_ to have happen. So this is the patch series I ended up with: [1/3]: t3030: fix accidental success in symlink rename [2/3]: merge: handle renames with replacement content [3/3]: merge: turn on rewrite detection -Peff -- 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