为啥 git log 可能不显示移动文件的历史记录,我该怎么办?
Posted
技术标签:
【中文标题】为啥 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 为我做了一些符合您预期的事情。 这是骗子吗? ***.com/questions/2314652/… 【参考方案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
不会提供任何重命名信息,如果您只是查看某个给定文件的历史记录,即使用文件参数。以上是关于为啥 git log 可能不显示移动文件的历史记录,我该怎么办?的主要内容,如果未能解决你的问题,请参考以下文章