ChatGPT解决这个技术问题 Extra ChatGPT

GIT 警告:太多文件跳过不准确的重命名检测

我知道默认的重命名限制是 100,我们可以使用配置 diff.renamelimit config 增加这个值

我担心的是,如果未设置此配置,是否会出现错误的合并或缺少任何代码?我正在尝试合并(git merge)2 个发生巨大变化的分支。

有人可以对此配置设置进行更多说明吗?

我有同样的经历,我可以确认该消息只是一个警告,除了一些讨厌的合并冲突之外没有任何后果。
我在 diff 命令上有这个警告

H
Hank Gay

您的内容是安全的。

据我了解,git 实际上没有任何一流 rename 操作的概念(只有 bzr 有,在三大 DVCS 中):mv 是底层机制之上的糖,它基本上是一个 add 和一个 rm。不过,由于 git 可以跟踪此类操作期间更改的内容,因此它可以使用启发式方法来猜测 addrm 何时实际上是 mv。由于这比仅显示 git 实际记录的内容需要更多的工作 - git-diff 的文档解释说它“...需要 O(n^2) 处理时间,其中 n 是潜在的重命名/复制目标的数量” —git 涉及的文件过多时不会尝试。您提到的设置仅控制该阈值。


“您的内容是安全的” - 虽然如果检测错过了在合并的一侧重命名并在另一侧更改的文件,您将遇到合并冲突,如果检测到重命名,您可能不会遇到。合并不会出错,但可能需要更多的用户努力才能完成。
感谢汉克和杰弗罗米。在任何情况下设置这个“diff.renamelimit config”真的有用吗?
如果有人也想知道此设置是否有用:是的,它可以帮助您在一个分支中移动数百个文件而在另一个分支中对这些文件进行大量更改时合并分支。当我在一个分支上进行大量代码重构而在另一个分支上进行一些持续工作时,我就遇到过这样的情况。
M
M3RS

万一这对任何人都有帮助,我在一个分支中有很多文件(数百个,如果不是数千个),而另一个分支中还没有。跑步

$ 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.

此外,在设置重命名限制后,在重试合并之前,调用“git merge --abort”以中止当前正在进行的合并。