如果我们将文件移动到不同的位置或重命名,除非我们专门使用git log --follow,否则它的所有先前历史记录都会在git log中丢失。我认为通常情况下,预期的行为是我们想要看到过去的历史记录,而不是在重命名或移动后“切断”,那么为什么git log不默认使用--follow标志呢?
dturner-tw
)。gitster
--于提交2dded96中合并,2015年8月3日)
log
:添加“log.follow
”配置变量在大多数线性历史记录且频繁重命名整个文件的项目中工作的人可能希望在检查单个路径中存在的内容的生命周期时始终使用“git log --follow
”。
当设置了log.follow
配置变量并且命令行上有一个(且仅有一个)路径时,教会命令表现得好像从命令行给出了“--follow
”一样。
git config log.follow true
注意:还有一个选项(奇怪的是,即使到了2020年和Git 2.25,仍没有文件记录),--no-follow
选项可以覆盖log.follow
配置设置。
Vser提出了一个补丁建议。
Jeff King (peff)指出了相同的提交我在讨论中提到的:提交aebbcf5,Git 1.8.2,2012年9月引入了--no-follow
。
follow=true
会隐藏合并提交,这在看似无害的命令中如 git log -- ./subproject
中体现得尤为明显。这几乎感觉像是 Git 的一个 bug,但它在各种操作系统和版本中都能够一致地表现出来,所以也许我对于当给定一个目录路径规范时 --follow
应该做什么存在误解。 - Borek Bernardgit -c log.follow= log
:这将取消 log.follow
,只针对该 git log
实例。 - VonC--follow
可能是有意义的。不跟随多个文件的原因可能是由于速度方面的考虑? - nonopolarity
git config log.follow true
选项:请参见下面的答案。 - VonC