Re: merge recursive and code movement

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