So Govind Salinas has found an interesting case in the rename detection code: $ git clone git://repo.or.cz/Widgit.git $ git diff -M --raw -r 192e^ 192e | grep .resx :100755 000000 4c8ab79... 0000000... D Form1.resx :100755 100755 9e70146... 9e70146... R100 CommitViewer.resx UI/CommitViewer.resx :100755 100755 90929fd... b40ff98... C091 RepoManager.resx UI/Form1.resx :100755 100755 90929fd... 90929fd... C100 PreferencesEditor.resx UI/PreferencesEditor.resx :100755 100755 90929fd... 90929fd... R100 PreferencesEditor.resx UI/RepoManager.resx :100755 100755 90929fd... 8535007... R097 RepoManager.resx UI/RepoTreeView.resx In this case several files had identical old images, and some kept that old image during the rename. Unfortunately because of the ordering of the files in the tree Git has decided to "rename" the PreferencesEditor.resx file to UI/RepoManager.resx, rather than renaming RepoManager.resx to UI/RepoManager.resx. Go Git. I'm wondering if we shouldn't play the game of trying to match delete/add pairs up by not only similarity, but also by path basename. In the case above its exactly what Govind thought should happen; he moved the file from one directory to another, and didn't even change its content during the move. But Git decided "better" to use a totally different file in the "rename". -- Shawn. - 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
