I've renamed a couple of files using git mv, used git stash, had a quick look at HEAD (without changing it) then did git stash pop to get the whole lot back again. My moves had disappeared from the commit list, so I redid them with git rm and the commit message claimed git had spotted the rename was a rename. So I thought no more of it.
But now, post-commit, I can't get at the history of the moved files! Here's what git says about the commit in question:
~/projects% git log --summary
commit de6e9fa2179ae17ec35a5c368d246f19da27f93a
Author: brone
Date: Wed Dec 8 22:37:54 2010 +0000
Moved R_DebugUI into runtime
delete mode 100644 test/R_DebugUI_iOS.h
delete mode 100644 test/R_DebugUI_iOS.m
create mode 100644 system/runtime/src/R_DebugUI_iOS.h
create mode 100644 system/runtime/src/R_DebugUI_iOS.m
<<snip older commits>>
~/projects%
I'm now trying to get the history of one of these moved files, so I can look at an old version, but I don't get anything very useful:
~/projects/system/runtime/src% git log --follow --find-copies-harder -M -C R_DebugUI_iOS.m
commit de6e9fa2179ae17ec35a5c368d246f19da27f93a
Author: brone
Date: Wed Dec 8 22:37:54 2010 +0000
Moved R_DebugUI into runtime
~/projects/system/runtime/src%
(I've also tried it without -M, -C and --find-copies-harder, but to no avail.)
I can get its history under its old name, which stops at the point it was deleted from its old location:
~/projects% git log --summary --follow --find-copies-harder -M -C -- test/R_DebugUI_iOS.m
commit de6e9fa2179ae17ec35a5c368d246f19da27f93a
Author: brone
Date: Wed Dec 8 22:37:54 2010 +0000
Moved R_DebugUI into runtime
delete mode 100644 test/R_DebugUI_iOS.m
commit 32a22d53c27e260714f759ecb3d3864e38b2e87f
Author: brone
Date: Tue Dec 7 23:52:51 2010 +0000
Can set debug UI's alpha.
<<snip older commits>>
~/projects%
So I'm not completely stuck this time, but I wouldn't fancy having to do this kind of thing all the time. (I anticipate having a fair number of files that will move at least once in their life.)
Am I doing something wrong? The old copy of the file and the new copy are 98.8% the same (2 lines out of 166 changed). My understanding is that git should be able to track the file in this case, because it infers rename operations rather than storing them explicitly, and the files are similar enough that I believe it should consider them the same.
Is there anything I can do to fix this?
Answering my own question, since I have managed to assuage my concerns, even if I haven't solved my problem exactly. (git log --follow still doesn't work for me, though.)
Firstly, the --summary log for the renaming commit includes the delete line with the file's old name. So if it's easy to spot, you can find its old name and git log from there.
If it's part of some large commit, and therefore a bit harder to spot -- and this situation was one of my worries -- git blame -C can be used with the file's new name on the first post-rename revision. Presumably lines remain from the original file! -- so git should find their source, and show old file name (and a commit hash for good measure). You can then pick up the trail with git log.
So, if you have some interest in the history of the file as a unit (for whatever reason) then it seems like it can be done relatively straightforwardly. Though I get the impression git would prefer that you used it properly.