From: Avery Pennarun Date: Wed, 03 Feb 2010 18:48:06 GMT Subject: Re: git-mv redux: there must be something else going on Message-ID: <32541b131002031048i26d166d9w3567a60515235c34@mail.gmail.com> In-Reply-To: On Wed, Feb 3, 2010 at 1:25 PM, Ron Garret 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