On Wed, Feb 3, 2010 at 1:25 PM, Ron Garret <ron1@xxxxxxxxxxx> wrote: > So something in my understanding of how git works must be wrong. Git > must be keeping a separate record of file renames somewhere. But where? It doesn't. Your experiment is wrong. > [ron@mickey:~/devel/gittest]$ cat>file2 > 6 > 7 > 8 > 9 > 10 > [ron@mickey:~/devel/gittest]$ git mv file2 file3 > [ron@mickey:~/devel/gittest]$ git commit -m 'letters->numbers' > [master ae3f6d4] letters->numbers > 1 files changed, 0 insertions(+), 0 deletions(-) > rename file2 => file3 (100%) Whoops. You didn't 'git add file2' (before the mv) or 'git add file3' (after the mv), or use commit -a, so what you've committed is the *old* content of file2 under the name file3. The *new* content of file2 is still uncommitted in your work tree under the name file3. This is why git can detect the move. (The 100% is a good clue: it means the old and new files are 100% identical.) Artificial tests like this are useless anyway. If you renamed file2 to file3 *and* changed all the contents, did you *really* rename it? If so, who cares? What good does it do you to know this? If someone else tries to patch the old file2 and you merge it into a (totally different) file3 vs a (now missing) file2, how is that any better? On the other hand, if one guy moves file2 to file3 and changes a few lines, you want the other guy's patch to go into file3, whether the first guy used 'git mv' or add+rm or anything else. As long as only a few lines changed, git does the right thing. If most/all of the lines have changed, then there is no right thing, because you'll get a nasty merge conflict either way. Have fun, Avery -- 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