Re: correct git merge behavior or corner case?

[Jeff King <peff@peff.net>]

On Mon, Apr 20, 2009 at 10:44:33PM -0400, Jeff King wrote:

> This is _exactly_ what git's rename detection is designed to do. Yes, it
> seems horribly confusing in this toy example, but that is because it is
> a toy example: both 'date' and 'LICENSE' are empty files. But with real
> files, if a source file has actual content but is deleted, there is a
> new filename with the identical or near-identical content, and the patch
> applies to the new content without conflicts, then applying it there is
> probably exactly what you want.

Looking back over the blog post, it seems that the original question was
not about a toy example, but what looks like some boilerplate that
involved empty files.

Maybe git should refuse to detect exact renames between empty files.
That is easy enough to special-case, and would help people who have
these sorts of boilerplate hierarchies. It would mean that we fail to
automatically resolve something like:

  $ touch foo && git add foo && git commit -m boilerplate
  $ git branch other
  $ echo content >foo && git commit -m 'fill in boilerplate'
  $ git checkout other
  $ git mv foo bar && git commit -m reorganize
  $ git merge master

But the failure case is actually quite reasonable. We just mark it as a
conflict, which is of course trivial for the user to resolve because the
ancestor, by definition, had nothing in it.

-Peff