执行 git push 时关于“diff.renamelimit 变量”的警告

Warning on "diff.renamelimit variable" when doing git push

提问by stid.smth

I'm pushing the local commit to the remote git server and got the following warning messages:

我将本地提交推送到远程 git 服务器并收到以下警告消息：

remote: warning: only found copies from modified paths due to too many files.
remote: warning: you may want to set your diff.renamelimit variable to at least 19824 and retry the command.

But actually I've already set the diff.renamelimit to 0 (I think zero means unlimited, right?).

但实际上我已经将 diff.renamelimit 设置为 0（我认为零意味着无限，对吧？）。

$ git config --list
...
diff.renamelimit=0

So what shall I do to avoid this warning? Thanks.

那么我该怎么做才能避免这个警告呢？谢谢。

采纳答案by VonC

The documentationdoesn't mention 0 as a special value for diff.renamelimit.
So you should set that limit to the value recommended.
Or you can try deactivating the rename detection altogether. (git config diff.renames 0)

该文件没有提及0作为一个特殊的价值diff.renamelimit。
因此，您应该将该限制设置为建议的值。
或者您可以尝试完全停用重命名检测。( git config diff.renames 0)

You will find a similar example in this blog post "Confluence, git, rename, merge oh my...":

你会在这篇博文“ Confluence，git，rename，merge oh my...”中找到一个类似的例子：

As already mentioned, git tries to detect file renames after that fact, for example when using git logor git diff/merge.
When trying to detect renames git distinguishes between exact and inexact renames with the former being a rename without changing the content of the file and the latter a rename that might include changes to the content of the file (e.g. renaming/moving a Java Class).
This distinction is important because the algorithm for detecting exact renames is linear and will always be executed while the algorithm for inexact rename detection is quadratic ( O(n^2)) and git does not attempt to do this if the number of files changed exceeds a certain threshold (1000 by default).

As the number of files affected by the recent reorganisation exceeds this threshold, git simply gives up and leaves the merge resolution up to the developer. In our case we can avoid doing manual merge resolution though by changing the threshold

如前所述，git 会尝试在此之后检测文件重命名，例如在使用git log或 时git diff/merge。
当尝试检测重命名时，git 区分精确重命名和不精确重命名，前者是不更改文件内容的重命名，后者是可能包括对文件内容进行更改的重命名（例如重命名/移动 Java 类）。
这种区别很重要，因为检测精确重命名的算法是线性的，并且将始终执行，而不精确重命名检测算法是二次 ( O(n^2)) 并且如果更改的文件数量超过某个阈值（1000默认）。

由于最近重组影响的文件数量超过了这个阈值，git 干脆放弃并将合并解决方案留给开发人员。在我们的例子中，我们可以通过改变阈值来避免手动合并解析

---

---

Note: Git 2.16 (Q1 2018) will amend that limit:

注意：Git 2.16（2018 年第一季度）将修改该限制：

Historically, the diff machinery for rename detection had a hardcoded limit of 32k paths; this is being lifted to allow users trade cycles with a (possibly) easier to read result.

历史上，用于重命名检测的 diff 机制硬编码限制为 32k 条路径；正在取消此功能以允许用户以（可能）更易于阅读的结果交易周期。

See commit 8997355(29 Nov 2017) by Jonathan Tan (jhowtan).
See commit 9268cf4, commit 9f7e4bf, commit d6861d0, commit b520abf(13 Nov 2017) by Elijah Newren (newren).
^{(Merged by Junio C Hamano -- gitster--in commit 6466854, 19 Dec 2017)}

请参阅Jonathan Tan ( ) 的提交 8997355（2017 年 11 月 29 日）。 请参阅Elijah Newren ( ) 的commit 9268cf4、commit 9f7e4bf、commit d6861d0、commit b520abf（2017 年 11 月 13 日）。^{（由Junio C Hamano合并-- --在提交 6466854 中，2017 年 12 月 19 日）}jhowtan
newren
gitster

diff: remove silent clamp of renameLimit

In commit 0024a54(Fix the rename detection limit checking; Sept. 2007, Git v1.5.3.2), the renameLimitwas clamped to 32767.
This appears to have been to simply avoid integer overflow in the following computation:

num_create * num_src <= rename_limit * rename_limit

Although it also could be viewed as a hard-coded bound on the amount of CPU time we're willing to allow users to tell git to spend on handling renames.
An upper bound may make sense, but unfortunately this upper bound was neither communicated to the users, nor documented anywhere.

Although large limits can make things slow, we have users who would be ecstatic to have a small five file change be correctly cherry picked even if they have to manually specify a large limit and wait ten minutes for the renames to be detected.

diff: 移除静音夹 renameLimit

在提交 0024a54（修复重命名检测限制检查；2007 年 9 月，Git v1.5.3.2）中，renameLimit被限制为 32767。
这似乎只是为了避免以下计算中的整数溢出：

num_create * num_src <= rename_limit * rename_limit

虽然它也可以被视为对 CPU 时间量的硬编码限制，但我们愿意允许用户告诉 git 花在处理重命名上。
上限可能有意义，但不幸的是，这个上限既没有传达给用户，也没有记录在任何地方。

尽管大限制会使事情变慢，但我们有用户会欣喜若狂，即使他们必须手动指定大限制并等待十分钟才能检测到重命名，但他们仍会欣喜若狂地正确挑选五个小文件更改。

Existing scripts and tools that use "-l0" to continue working, treating 0 as a special value indicating that the rename limit is to be a very large number.

使用“ -l0”继续工作的现有脚本和工具，将 0 视为一个特殊值，表示重命名限制是一个非常大的数字。

---

---

Git 2.17 (Q2 2018) will avoid showing a warning message in the middle of a line of "git diff" output.

Git 2.17（2018 年第二季度）将避免在“ git diff”输出行中间显示警告消息。

See commit 4e056c9(16 Jan 2018) by Nguy?n Thái Ng?c Duy (pclouds).
^{(Merged by Junio C Hamano -- gitster--in commit 17c8e0b, 13 Feb 2018)}

请参阅Nguy?n Thái Ng?c Duy ( ) 的提交 4e056c9（2018 年 1 月 16 日）。^{（由Junio C Hamano合并-- --在commit 17c8e0b，2018 年 2 月 13 日）}pclouds
gitster

diff.c: flush stdoutbefore printing rename warnings

The diff output is buffered in a FILEobject and could still be partially buffered when we print these warnings (directly to fd 2).
The output is messed up like this

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 +-

It gets worse if the warning is printed after color codes for the graph part are already printed. You'll get a warning in green or red.

Flush stdout first, so we can get something like this instead:

如果在已经打印图形部分的颜色代码之后打印警告，情况会变得更糟。您会收到绿色或红色警告。

首先刷新标准输出，所以我们可以得到这样的东西：

 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.

回答by Serge Seletskyy

git config merge.renameLimit 999999

What does merge.renameLimitmean

merge.renameLimit是什么意思

The number of files to consider when performing rename detection during a merge; if not specified, defaults to the value of diff.renameLimit.

在合并期间执行重命名检测时要考虑的文件数量；如果未指定，则默认为diff.renameLimit的值。

source: https://git-scm.com/docs/git-merge

来源：https: //git-scm.com/docs/git-merge