GIT 警告：太多文件跳过不精确的重命名检测
我知道默认的重命名限制是100，我们可以使用配置 diff.renamelimit config 来增加这个值，
我担心的是，如果不设置这个配置，会不会出现错误合并或缺少任何代码？ 我正在尝试合并（git merge）两个有巨大变化的分支。
有人可以更详细地了解此配置设置吗？
I am aware that the default rename limit is 100 and we can increase this value using the config diff.renamelimit config
What I am worried about is that, if this config is not setup, will there be a wrong merge or any missing code?
I am trying to merge (git merge) 2 branches that have huge changes.
Can someone throw more light about this config setting?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果这对任何人有帮助，我在一个分支中有很多文件（数百个，如果不是数千个），而这些文件尚未在另一个分支中。 运行出现以下错误
合并消失时
In case this helps anyone, I had a lot of files (hundreds, if not thousands) in one branch, which were not yet in the other branch. Running
made the below error when merging go away
您的内容是安全的。
据我了解，
git实际上没有任何一流的 <code>rename 操作的概念（三大巨头中只有bzr有） DVCS）：mv是底层机制之上的糖，它基本上是一个add和一个rm。不过，由于git可以跟踪此类操作期间更改的内容，因此它可以使用启发式方法来猜测add和rm何时实际上是一个mv。因为这比仅仅显示 git 实际记录的内容需要更多的工作 - git-diff 的文档解释说它“...需要 O(n^2) 处理时间其中 n 是潜在的重命名/复制目标的数量”——当涉及太多文件时，git不会尝试它。您提到的设置仅控制该阈值。Your content is safe.
As I understand it,
gitdoesn't actually have any concept of a first-classrenameoperation (onlybzrdoes, of the big 3 DVCSs): themvis sugar on top of the underlying machinery, which is basically anaddand arm. Sincegitcan track the content that changes during such operations, though, it can use heuristics to guess when anaddand armare actually amv. Since that takes way more work than just displaying whatgitactually recorded—the docs forgit-diffexplain that it "...require O(n^2) processing time where n is the number of potential rename/copy targets"—gitwon't try it when too many files are involved. The setting you mention just controls that threshold.