为什么 git log 可能不显示移动文件的历史记录，我该怎么办？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4393527/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why might git log not show history for a moved file, and what can I do about it?
提问by liang
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 popto get the whole lot back again. My moves had disappeared from the commit list, so I redid them with git rmand the commit message claimed git had spotted the rename was a rename. So I thought no more of it.
我使用git mv, used重命名了几个文件，git stash快速查看了 HEAD（没有更改它），然后git stash pop再次将整个文件取回。我的动作已经从提交列表中消失了，所以我重新修改了它们，git rm提交消息声称 git 发现重命名是重命名。于是我就不再多想了。
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:
但是现在，提交后，我无法获得移动文件的历史记录！以下是 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%
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, -Cand --find-copies-harder, but to no avail.)
（我也试过没有-M,-C和--find-copies-harder，但无济于事。）
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.
难道我做错了什么？文件的旧副本和新副本的 98.8% 相同（166 行中有 2 行已更改）。我的理解是在这种情况下 git 应该能够跟踪文件，因为它推断重命名操作而不是显式存储它们，并且文件足够相似，我相信它应该将它们视为相同。
Is there anything I can do to fix this?
我能做些什么来解决这个问题吗？
采纳答案by user502515
Answering my own question, since I have managed to assuage my concerns, even if I haven't solved my problem exactly. (git log --followstill doesn't work for me, though.)
回答我自己的问题，因为我已经设法缓解了我的担忧，即使我还没有完全解决我的问题。（不过，git log --follow仍然对我不起作用。）
Firstly, the --summarylog for the renaming commit includes the deleteline with the file's old name. So if it's easy to spot, you can find its old name and git logfrom there.
首先，--summary重命名提交的日志包括delete具有文件旧名称的行。因此，如果它很容易被发现，您可以git log从那里找到它的旧名称。
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 -Ccan 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.
如果它是某个大型提交的一部分，因此更难发现——这种情况是我的担忧之一——git blame -C可以在第一次重命名后修订中与文件的新名称一起使用。据推测，原始文件中保留了几行！-- 所以 git 应该找到它们的来源，并显示旧的文件名（以及一个提交哈希作为很好的衡量标准）。然后，您可以使用 选择路径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.
因此，如果您对作为一个单元的文件的历史记录感兴趣（无论出于何种原因），那么它似乎可以相对简单地完成。虽然我的印象是 git 更喜欢你正确使用它。
回答by liang
Please have a try with git log --followon your file. I learn from here Is it possible to move/rename files in git and maintain their history?
请尝试使用git log --follow您的文件。我从这里学习是否可以在 git 中移动/重命名文件并维护它们的历史记录？
回答by user502515
Well, I do see my renames with git log -M --summary..
好吧，我确实看到我的重命名为git log -M --summary..
回答by janetkuo
git log --follow ./path/to/file
I believe this is what you're looking for.
我相信这就是你要找的。
