为什么 git log 可能不显示移动文件的历史记录，我该怎么办？答案

【问题标题】：Why might git log not show history for a moved file, and what can I do about it?为什么 git log 可能不显示移动文件的历史记录，我该怎么办？
【发布时间】：2011-05-22 13:36:36
【问题描述】：

我使用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 应该能够跟踪文件，因为它推断重命名操作而不是显式存储它们，并且文件足够相似，我相信它应该认为它们是相同的。

有什么办法可以解决这个问题吗？

【问题讨论】：

猜猜：如果你在 ~/projects/ 里面执行命令而不是 ~/projects/system/runtime/src 会有效吗？
不，我得到了相同的结果。（通常 git 似乎很适合让你在任何文件夹中......）
这给了我一个想法，我用我的发现更新了这个问题。感谢您的评论！
我在 mswindows 上使用“tortoiseGit 1.5.8.0”和“1.7.3.1.msysgit.0”。当我在资源管理器中重命名+提交文件时，我在我的 gui 中看到“状态 = 重命名”。我不太了解 git 如何在命令行中执行此操作来回答“如何执行此操作”，但 tortoiseGit 为我做了一些符合您预期的事情。
这是骗子吗？ stackoverflow.com/questions/2314652/…

标签： git history dvcs rename git-log

【解决方案1】：

git log --follow ./path/to/file

我相信这就是你要找的。p>

【讨论】：

五年前的答案有这个信息。

【解决方案2】：

请尝试在您的文件中使用git log --follow。我从这里学习Is it possible to move/rename files in git and maintain their history?

【讨论】：

如果你得到fatal: ambiguous argument 'file.txt': unknown revision or path not in the working tree，试试 git log --follow --file.txt

【解决方案3】：

回答我自己的问题，因为我已经设法缓解了我的担忧，即使我没有完全解决我的问题。（不过，git log --follow 仍然对我不起作用。）

首先，重命名提交的--summary 日志包含带有文件旧名称的delete 行。因此，如果它很容易被发现，您可以从那里找到它的旧名称和git log。

如果它是某个大型提交的一部分，因此更难发现——这种情况是我的担忧之一——git blame -C 可以在第一次重命名后修订中与文件的新名称一起使用。大概是原始文件中的行！ -- 所以 git 应该找到它们的来源，并显示旧文件名（以及一个提交哈希值）。然后您可以通过git log 获取线索。

因此，如果您对文件作为一个单元的历史感兴趣（无论出于何种原因），那么它似乎可以相对简单地完成。虽然我觉得 git 更喜欢你正确使用它。

【讨论】：

我认为您需要 -M 选项来实际显示重命名而不是删除/添加
刚刚遇到同样的问题，并注意到您的工作目录有所不同git log --follow . 工作目录是新位置的位置不起作用，而git log --follow path/to/new/dir，从公共父目录执行旧的和新的位置，作品
--follow 参数确实有效，但您需要这样做：git log --follow -- ./path/to/file
我刚刚遇到git -log filename.cs 在文件移动提交时停止的问题（当前目录设置为文件的文件夹）。但是 VS 历史窗口显示整个文件更改日志。我还可以看到该文件已使用 Github 桌面移动。但是git log -10 --follow filename.cs 也显示了移动提交之前的日志。

【解决方案4】：

嗯，我确实看到我的重命名为 git log -M --summary..

【讨论】：

git log -M --summary 不会提供任何重命名信息，如果您只是查看某个给定文件的历史记录，即使用文件参数。