Re: correct git merge behavior or corner case?

From: Jeff King <peff@peff.net>
Date: Apr 21, 2009, 02:51 UTC
Message-ID: <20090421025107.GD14479@coredump.intra.peff.net>
In-Reply-To: <20090421024433.GC14479@coredump.intra.peff.net>

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

Show 7 quoted lines

> 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