当前位置：文江博客话题详情

Git push warnings

关于“diff.renamelimit 变量”的警告进行 git Push 时

发布于 2024-12-11 05:05:55 字数 404 浏览 0 评论 0 原文

我将本地提交推送到远程 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.

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

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

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

原文

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

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?).

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

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

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

鹿港小镇 2024-12-18 05:05:55

git config merge.renameLimit 999999

merge.renameLimit 是什么意思

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

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

git config merge.renameLimit 999999

What does merge.renameLimit mean

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

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

回复收藏 0 原文

黑寡妇 2024-12-18 05:05:55

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

您将在这篇博文“

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

当受最近重组影响的文件数量超过此阈值时，git 会直接放弃，并将合并解决方案留给开发人员。在我们的例子中，我们可以通过更改阈值来避免进行手动合并解析

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

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

请参阅提交 8997355（2017 年 11 月 29 日），作者：乔纳森·谭（jhowtan）。
请参阅提交9268cf4，提交 9f7e4bf, 提交 d6861d0, 提交 b520abf（2017 年 11 月 13 日），作者：以利亚纽伦（newren）。
^{（由 Junio C Hamano -- gitster -- 合并于提交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 花在处理上的时间
重命名。
上限可能是有意义的，但不幸的是这个上限
bound 既没有传达给用户，也没有记录在任何地方。

虽然较大的限制可能会使速度变慢，但我们有一些用户会
即使他们必须手动指定一个大的限制并等待十分钟才能检测到重命名，也很高兴能够正确地挑选出一个小的五个文件更改。

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

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

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

diff.c：在打印重命名警告之前刷新stdout

差异输出缓冲在 FILE 对象中，并且仍然可以
当我们打印这些警告时（直接打印到fd 2），部分缓冲。
输出是这样混乱的

<前><代码>worktree.c | 138+-
worktree.h 警告：由于文件太多，跳过了不精确的重命名检测。
| 12+-
包装器.c | 83+-

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

首先刷新标准输出，这样我们就可以得到类似这样的东西：
xdiff/xutils.c | 42+-
xdiff/xutils.h | 4+-
1033 个文件已更改，150824 个插入(+)，69395 个删除(-)
警告：由于文件太多，跳过了不精确的重命名检测。

With Git 2.33 (Q3 2021), Documentation on "git diff -l"^{(man )} 和 diff.renameLimit 已更新，并且这些限制的默认值已提高。

请参阅提交94b82d5，提交 9dd29db, 提交 6623a52, 提交 05d2c61（2021 年 7 月 15 日），作者：以利亚纽伦（newren）。
^{（由 Junio C Hamano -- gitster -- 合并于提交268055b，2021 年 7 月 28 日）}

diffcore-rename：处理 rename_limit 为 0 表示无限制

^{签字人：伊利亚·纽伦}

在提交8997355中（“diffcore-rename：使 diff-tree -l0 表示 -l", 2017-11-29，Git v2.16.0-rc0 -- 合并在batch #10)，-l0 被赋予了一个特殊的神奇“大" 值，但对于某些用途来说还不够大（从提交 9f7e4bf ("diff: 删除 renameLimit 的静默限制”，2017-11-13，Git v2.16.0-rc0 -- 合并在第 10 批）。将 0（或负值）视为无限制，并更新文档以提及这一点。

diff-options 现在包含在其手册页：

请注意，值 0 被视为无限制。

The documentation doesn'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)

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

As already mentioned, git tries to detect file renames after that fact, for example when using git log or 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

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

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.

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)}

diff: remove silent clamp of renameLimit

In commit 0024a54 (Fix the rename detection limit checking; Sept. 2007, Git v1.5.3.2), the renameLimit was 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.

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.

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

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)}

diff.c: flush stdout before printing rename warnings

The diff output is buffered in a FILE object and could still be
partially buffered when we print these warnings (directly to fd 2).
The output is messed up like this
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.

With Git 2.33 (Q3 2021), documentation on "git diff -l<n>"^(man) and diff.renameLimit have been updated, and the defaults for these limits have been raised.

See commit 94b82d5, commit 9dd29db, commit 6623a52, commit 05d2c61 (15 Jul 2021) by Elijah Newren (newren).
^{(Merged by Junio C Hamano -- gitster -- in commit 268055b, 28 Jul 2021)}

diffcore-rename: treat a rename_limit of 0 as unlimited

^{Signed-off-by: Elijah Newren}

In commit 8997355 ("diffcore-rename: make diff-tree -l0 mean -l", 2017-11-29, Git v2.16.0-rc0 -- merge listed in batch #10), -l0 was given a special magical "large" value, but one which was not large enough for some uses (as can be seen from commit 9f7e4bf ("diff: remove silent clamp of renameLimit", 2017-11-13, Git v2.16.0-rc0 -- merge listed in batch #10).
Make 0 (or a negative value) be treated as unlimited instead and update the documentation to mention this.

diff-options now includes in its man page:

Note that a value of 0 is treated as unlimited.

回复收藏 0 原文

徒留西风 2024-12-18 05:05:55

如果您不是经常遇到这个问题，而是它只是一次性的事情，那么更改全局配置的默认值可能是一种矫枉过正。我建议您只需使用 -c 选项来为这个命令设置一个特殊的配置。像这样的东西：

git -c "diff.renamelimit=19824" push

In case you aren't constantly running into this problem, but instead it's just a one-off thing then changing the global config from it's default value might be an overkill. I would suggest you simply use the -c option to set a special config just for this one command. Something like:

git -c "diff.renamelimit=19824" push

回复收藏 0 原文

~没有更多了~

关于作者

毁我热情

暂无简介

0 文章

0 评论

23 人气

关注发私信

友情链接

文江博客

关于“diff.renamelimit 变量”的警告进行 git Push 时

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

评论（3）

`diff`：删除 `renameLimit`

`diff.c`：在打印重命名警告之前刷新`stdout`

`diffcore-rename`：处理 `rename_limit` 为 0 表示无限制

`diff`: remove silent clamp of `renameLimit`

`diff.c`: flush `stdout` before printing rename warnings

`diffcore-rename`: treat a `rename_limit` of 0 as unlimited

关于作者

相关话题

热门标签

推荐作者

醉城メ夜风

远昼

平生欢

微凉

Honwey

qq_ikhFfg

友情链接

关于“diff.renamelimit 变量”的警告进行 git Push 时

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

评论（3）

diff：删除 renameLimit

diff.c：在打印重命名警告之前刷新stdout

diffcore-rename：处理 rename_limit 为 0 表示无限制

diff: remove silent clamp of renameLimit

diff.c: flush stdout before printing rename warnings

diffcore-rename: treat a rename_limit of 0 as unlimited

关于作者

相关话题

热门标签

推荐作者

醉城メ夜风

远昼

平生欢

微凉

Honwey

qq_ikhFfg

友情链接

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

`diff`：删除 `renameLimit`

`diff.c`：在打印重命名警告之前刷新`stdout`

`diffcore-rename`：处理 `rename_limit` 为 0 表示无限制

`diff`: remove silent clamp of `renameLimit`

`diff.c`: flush `stdout` before printing rename warnings

`diffcore-rename`: treat a `rename_limit` of 0 as unlimited