为什么git log不显示移动文件的历史记录，我该怎么做？

3lxsmp7m 于 2023-01-15 发布在 Git

关注(0)|答案(5)|浏览(349)

我用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

来源：https://stackoverflow.com/questions/4393527/why-might-git-log-not-show-history-for-a-moved-file-and-what-can-i-do-about-it

5条答案

按热度按时间

8cdiaqws1#

在您的文件上尝试git log --follow。
Is it possible to move/rename files in Git and maintain their history?

赞(0）回复(0）举报 2023-01-15

dy2hfwbg2#

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

赞(0）回复(0）举报 2023-01-15

2vuwiymt3#

回答我自己的问题，因为我已经设法减轻了我的担忧，即使我还没有完全解决我的问题。（尽管git log --follow仍然不适合我。）
首先，重命名提交的--summary日志包含delete行和文件的旧名称，所以如果很容易发现，你可以从那里找到它的旧名称和git log。
如果它是某个大型提交的一部分，因此有点难以识别--这种情况是我担心的--git blame -C可以在重命名后的第一次修订中与文件的新名称一起使用。据推测，原始文件中的行仍然存在！--因此git应该找到它们的源代码，并显示旧文件名（以及一个提交哈希值），然后可以使用git log来跟踪。
所以，如果你对文件作为一个单元的历史感兴趣（不管出于什么原因），那么看起来可以相对简单地完成它，尽管我得到的印象是git希望你正确地使用它。