On Mon, Apr 20, 2009 at 12:10:35PM +0200, Anders Melchiorsen wrote: > I think that I managed to recreate what he is describing. > > > #!/bin/bash > > cd $(mktemp -d repo.XXXXX) > > git init > > touch date > git add date > git commit -memptydate > > git branch parallel > > touch LICENSE > git add LICENSE > git commit -mLICENSE > > git checkout parallel > date >date > git add date > git commit -mdate > > git checkout master > git rm date > git commit -mnodate > > git merge parallel > > cat LICENSE So basically one branch removes a file and adds an identical file under a different name, while the other branch modifies the original file. Git detects it as a rename, and applies the change from the second branch to the newly added file instead of generating a conflict. 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. The only complaint I have in that example is that there is nothing indicating to the user that the patch was applied to a renamed version. The output I get is: $ git merge parallel Merge made by recursive. LICENSE | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) Perhaps a note indicating that it applied changes for "date" to "LICENSE" would be helpful. -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