GIT警告：太多的文件，跳过不精确的重命名检测。

Question

我知道默认的重命名限制是100，我们可以使用配置 diff.renamelimit config 来增加此值。

我的担忧是，如果没有设置此配置，是否会出现错误合并或任何遗漏的代码？ 我正在尝试合并（git merge）两个具有大量更改的分支。

有人能够更详细地解释一下这个配置设置吗？

- Senthil A Kumar

---

我有同样的经历，我可以确认这个消息只是一个警告，除了一些烦人的合并冲突之外没有任何后果。 - Johan H

我在diff命令上收到了这个警告。 - JobaDiniz

Answer 1

如果有人需要帮助，我的情况可能会对你有所帮助。我在一个分支中有许多文件（数以百计，如果不是数以千计），而这些文件在另一个分支中还不存在。运行

$ git config merge.renamelimit 15345

在合并时出现了以下错误，请离开

$ git merge master
.
.
.
warning: inexact rename detection was skipped due to too many files.
warning: you may want to set your merge.renamelimit variable to at least 15345 and retry the command.

- M3RS

---

另外，在设置重命名限制后，在重试合并之前，请调用“git merge --abort”来中止当前正在进行的合并。 - robbie fan

Answer 2

您的内容是安全的。

据我所知，git 实际上没有任何一流的 rename 操作概念（仅有的三大分布式版本控制系统中的 bzr 有这个概念）： mv只是在底层机制之上加了些糖，基本上就是一个 add 和一个 rm。虽然如此，由于 git 可以跟踪在此类操作期间发生更改的内容，因此它可以使用启发式方法来猜测何时 add 和 rm 实际上是 mv。由于这需要的工作量比仅显示 git 实际记录的内容多得多，git-diff 的文档解释说它 "...需要 O(n^2) 处理时间，其中 n 是潜在的重命名/复制目标数量"。因此，在涉及太多文件时，git 不会尝试执行该操作。您提到的设置只是控制了阈值。

- Hank Gay

---

“您的内容是安全的” - 但是，如果合并时在其中一侧重命名了文件并在另一侧进行了更改而检测遗漏了该文件，则可能会出现合并冲突。这些合并冲突不会导致合并结果“错误”，但可能需要用户更多的努力来完成合并。 - Cascabel

感谢Hank和Jefromi。在任何情况下，设置“diff.renamelimit config”是否真的有用？ - Senthil A Kumar

如果有人想知道这个设置是否有用：是的，它可以帮助你在一个分支上移动了数百个文件，在另一个分支上对这些文件进行了很多更改时合并分支。我曾经遇到过这样的情况，当时我在一个分支上进行了大量的代码重构，在另一个分支上则有一些正在进行中的工作。 - korda