该文件没有提及0作为一个特殊的价值diff.renamelimit
。
因此,您应该将该限制设置为建议的值。
或者,您可以尝试完全停用重命名检测。(git config diff.renames 0
)
您将在此博客文章“ Confluence,git,重命名,合并哦,我的... ”中找到类似的示例:
如前所述,git尝试在该事实之后检测文件重命名,例如在使用git log
或时git diff/merge
。
尝试检测重命名时,git区分精确重命名和不精确重命名,前者是不更改文件内容的重命名,而后者是可能包含文件内容更改(例如重命名/移动Java类)的重命名。
这种区别很重要,因为用于检测精确重命名的算法是线性的,并且将始终执行,而用于不精确重命名检测的算法是二次方(O(n^2)
),并且如果更改的文件数超过特定阈值(1000次,则git不会尝试执行此操作)默认)。
由于受最近重组影响的文件数超过了此阈值,因此git只是放弃了,将合并分辨率留给了开发人员。在我们的情况下,我们可以通过更改阈值来避免执行手动合并解析
注意:Git 2.16(Q1 2018)将修改该限制:
从历史上看,用于重命名检测的diff机器的硬编码限制为32k路径。解除了这一限制,以使用户可以(更容易)读取结果进行交易。
参见Jonathan Tan()提交的8997355(2017年11月29日)。
请参见Elijah Newren()的提交9268cf4,提交9f7e4bf,提交d6861d0和提交b520abf(2017年11月13日)。(由Junio C Hamano合并--在6466854号提交中,2017年12月19日)jhowtan
newren
gitster
diff
:取下静音夹 renameLimit
在提交0024a54中(修复了重命名检测限制检查; 2007年9月,Git v1.5.3.2),将renameLimit
其限制为32767。
这似乎是为了在以下计算中避免整数溢出:
num_create * num_src <= rename_limit * rename_limit
尽管也可以将其视为对CPU时间的硬编码限制,我们还是愿意允许用户告诉git花在处理重命名上。
上限可能是有道理的,但不幸的是,该上限既未传达给用户,也未记录在任何地方。
尽管较大的限制会使操作变慢,但是我们仍然希望那些只希望对五个文件进行较小更改的用户正确地选择樱桃,即使他们必须手动指定较大的限制并等待十分钟才能检测到重命名。
现有的脚本和工具使用“ -l0
”继续工作,将0作为特殊值来表示重命名限制将是一个很大的数字。
Git 2.17(2018年第二季度)将避免在“ git diff
”输出行的中间显示警告消息。
见提交4e056c9通过(2018年1月16日)阮泰玉维战(pclouds
)。
(由Junio C gitster
Hamano合并--在commit 17c8e0b中,2018年2月13日)
diff.c
:stdout
在打印重命名警告之前先冲洗
diff输出缓冲在一个FILE
对象中,当我们打印这些警告时(直接发送到fd 2
),仍可以部分缓冲。
这样就把输出弄乱了
worktree.c | 138 +-
worktree.h warning: inexact rename detection was skipped due to too many files.
| 12 +-
wrapper.c | 83 +-
如果已经打印了图形部件的颜色代码后再打印警告,则情况会更糟。您会收到绿色或红色的警告。
首先刷新stdout,所以我们可以得到以下内容:
xdiff/xutils.c | 42 +-
xdiff/xutils.h | 4 +-
1033 files changed, 150824 insertions(+), 69395 deletions(-)
warning: inexact rename detection was skipped due to too many files.
merge.renameLimit
代替diff.renameLimit
?