git config merge.renameLimit 999999

merge.renameLimit是什么意思

在合并期间执行重命名检测时要考虑的文件数;如果未指定，则默认为diff.renameLimit的值。
来源：https://git-scm.com/docs/git-merge

documentation没有提到0是diff.renamelimit的特殊值。
因此，您应该将该限制设置为建议的值。
或者您可以尝试完全停用重命名检测。（git config diff.renames 0）
你会在这篇博客文章“Confluence, git, rename, merge oh my...”中找到一个类似的例子：
如前所述，git会在此之后尝试检测文件重命名，例如使用git log或git diff/merge时。
当尝试检测重命名时，git会区分精确重命名和不精确重命名，前者是不改变文件内容的重命名，后者是可能包含文件内容更改的重命名（例如重命名/移动Java类）。
这个区别很重要，因为检测精确重命名的算法是线性的，并且总是会被执行，而检测不精确重命名的算法是二次的（O(n^2)），并且如果更改的文件数量超过某个阈值（默认为1000），git不会尝试这样做。
由于最近的重组影响的文件数量超过了这个阈值，git就放弃了，并将合并解决方案留给开发人员。
注意：Git 2.16（Q1 2018）将修改该限制：
历史上，用于重命名检测的diff机制具有32 k路径的硬编码限制;这是被解除，以允许用户贸易周期与（可能）更容易阅读的结果。
参见commit 8997355（2017年11月29日），作者Jonathan Tan ( jhowtan )。
请参阅commit 9268cf4，commit 9f7e4bf，commit d6861d0，commit b520abf（13 Nov 2017）by Elijah Newren ( newren )。
（由Junio C Hamano -- gitster --合并于commit 6466854，2017年12月19日）

diff：拆下renameLimit的无声夹

在commit 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（Q2 2018）将避免在输出“git diff“的行中间显示警告消息。
参见commit 4e056c9（2018年1月16日），作者Nguyễn Thái Ngọc Duy ( pclouds )。
（由Junio C Hamano -- gitster --合并于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.

在Git 2.33（2021年第3季度）中，有关“git diff -l<n>”（man）和diff.renameLimit的文档已更新，并且这些限制的默认值已提高。
参见commit 94b82d5、commit 9dd29db、commit 6623a52、commit 05d2c61（2021年7月15日）by Elijah Newren ( newren )。
（由Junio C Hamano -- gitster --合并于commit 268055b，2021年7月28日）

diffcore-rename：将0的rename_limit视为无限制

签字人：伊莱贾·纽伦
在commit 8997355（“diffcore-rename：make diff-tree -l0 mean -l”，2017-11-29，Git v2.16.0-rc 0--merge listed in batch #10），-l0被赋予了一个特殊的神奇的“large”值，但对于某些用途来说，这个值不够大（从commit 9f7e4bf（“diff：remove silent clamp of renameLimit“，2017-11-13，Git v2.16.0-rc0 -- merge listed in batch #10）.
将0（或负值）视为无限制，并更新文档以提及这一点。
diff-options现在在其手册页中包括：
请注意，值0被视为无限制。

如果你不是经常遇到这个问题，而是它只是一个一次性的事情，那么改变全局配置从它的默认值可能是一个矫枉过正。我建议你简单地使用-c选项设置一个特殊的配置只为这一个命令。类似于：

git -c "diff.renamelimit=19824" push