Re: merge recursive and code movement

From: Jeff King <peff@peff.net>
Date: Mar 25, 2011, 16:00 UTC
Message-ID: <20110325160013.GA25851@sigill.intra.peff.net>
In-Reply-To: <20110325111225.GC9047@sigill.intra.peff.net>

On Fri, Mar 25, 2011 at 07:12:25AM -0400, Jeff King wrote:

Show 11 quoted lines

> 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