为什么 git 日志不显示移动文件的历史记录，我能做些什么呢？

我使用 git mv重命名了几个文件，使用 git stash，快速查看了一下 HEAD (没有更改它) ，然后使用 git stash pop将整个文件重新命名。我的移动已经从提交列表中消失了，所以我用 git rm重做了它们，提交消息声称 git 发现了重命名。所以我不再想了。

但是现在，后提交，我无法获得移动文件的历史记录！下面是 git 对提交的描述:

~/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%

我现在尝试获取其中一个移动文件的历史记录，这样我就可以查看一个旧版本，但我没有得到任何非常有用的东西:

~/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%

(我也试过不使用 -M、 -C和 --find-copies-harder，但没有用。)

我可以用它原来的名字找到它的历史记录从它原来的位置被删除的时候就结束了:

~/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%

所以这次我没有完全被困住，但是我不想一直做这种事情。(我预计会有相当数量的文件在一生中至少移动一次。)

我做错什么了吗？文件的旧副本和新副本的相同度为98.8% (166行中有2行发生了更改)。我的理解是，在这种情况下，git 应该能够跟踪文件，因为它推断出重命名操作，而不是显式地存储它们，而且这些文件非常相似，我相信 git 应该将它们视为相同的。

我能做些什么来弥补这一切吗？

48349

小开

最佳答案

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.