Re: merge recursive and code movement

[Jeff King <peff@peff.net>]

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