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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html