git推送到远程错误: remote: warning: inexact rename detection was skipped due to too many files

Question

在我的机器上完成发布后... git flow release finish 'X.X.XXX.X' 然后我必须将新版本推送到 origin。所以我运行这些命令...

$ git push origin --tags (this works, results omitted)
$ git checkout develop (this works, results omitted)
$ git push (this works, results omitted)
$ git checkout master (this works, results omitted)
$ git push (this is what fails)
Total 0 (delta 0), reused 0 (delta 0)
remote: warning: inexact rename detection was skipped due to too many files.
remote: warning: you may want to set your diff.renameLimit variable to at least 1804 and retry the command.

因此，我阅读了许多 SO 帖子和 git-config 文档。根据我阅读的内容，我在我的配置中设置了这些值...

$ git config merge.renameLimit 999999
$ git config diff.renameLimit 999999
$ git config diff.renames copies

这会在配置文件中产生这样的结果...

[merge]
    renameLimit = 999999
[diff]
    renameLimit = 999999
    renames = copies

但是同样的错误发生了。我不确定还能尝试什么。 999999 是不是太高了？是否有不能超过的限制才能正常工作？对于 diff.renames 应该是 copies 还是带双引号的 "copies"？我会尝试所有这些选项，只是需要很长时间才能重新设置测试场景。 The documentation说 diff.renames 默认为 true 但是当我查看我的配置时它不存在，这就是我添加 copies 的原因。

这是我的完整配置文件，希望对您有帮助...

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true
    symlinks = false
    ignorecase = true
[remote "origin"]
    url = https://github.xxxxxx.com/gfrobenius/xxxxxx.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "develop"]
    remote = origin
    merge = refs/heads/develop
[branch "master"]
    remote = origin
    merge = refs/heads/master
[gitflow "branch"]
    master = master
    develop = develop
[gitflow "prefix"]
    feature = feature/
    bugfix = bugfix/
    release = release/
    hotfix = hotfix/
    support = support/
    versiontag = 
[gitflow "path"]
    hooks = C:/Users/gfrobenius/Sites/gfrobenius/xxxxxx/.git/hooks
[merge]
    renameLimit = 999999
[diff]
    renameLimit = 999999
    renames = copies

Answer 1

remote: warning: inexact rename detection was skipped due to too many files.

您在 git push 期间看到的任何以 remote: 为前缀的消息都不是来自 你的 Git 但来自他们的 Git。您在自己的存储库中所做的任何设置都不会影响它。¹

如果他们——无论接收你的 git push 的“他们”是谁——有一个正常的日常存储库，你的 git push 来自你的 master 会将您的提交发送给他们，并要求他们设置他们的 master 以识别与您的 master 相同的提交。这要么立即成功(因为您要求他们设置的提交是他们已经作为他们的 master 提交的提交的后代)，要么立即失败(因为它不是)。

因此我们可以得出结论，无论他们是谁，当您的 git push 要求他们的 Git 更新他们的 master 时，他们已经幻想他们的存储库运行一些特殊的操作。他们的这个特殊 Action 现在正在运行，并执行某种 git diff 命令。 (该操作可能是通过 Git Hook ，例如预接收或更新 Hook 。)

他们的 Git 需要调整其重命名限制，以处理两者之间的差异......好吧，我们不知道他们是什么 git diff-ing!我们只知道他们在运行 git diff!所以这是我们必须猜测的点。他们可以做一些合理的事情，还有更多不合理的事情。

他们几乎肯定在做:

git diff <hash1> <hash2>

hash1 值可能是其master 的当前值。如果是这样，您可以运行 git fetch(或者甚至只是 git ls-remote)来查看什么哈希 ID 他们的 master代表。 hash2 值可能是您称为 master 的存储库中提交的哈希 ID，在这种情况下你可以只使用你自己的名字master。

如果我们的所有猜测都正确，并且还正确地猜测了他们在他们的配置中设置的任何设置，我们也许能够重现出现的任何问题在他们的预接收或更新 Hook 中。

当然，仅仅能够重现它并不能使我们修复它。只有他们才能真正解决问题。充其量，我们可以通过推送不同的提交来解决它。

此时正确的做法是询问他们在做什么，为什么这样做，以及您是否可以通过某种方式为他们改进。如果失败，然后沿着这条半死胡同走下去，猜测他们在做什么，为什么，以及您是否可以以及如何解决他们的错误。

---

¹现代 Git 实际上有一种方法可以在 git push 期间将特定的 variable = value 设置从一个 Git 发送到另一个 Git。默认情况下，这些对接收 Git 完全没有影响，因为否则你就可以用这些选项欺骗现有的、设置简单的 Git 接收者。但是我们知道他们有一些他们正在使用的脚本，来自 Git 钩子(Hook)；此脚本可能实际上会查找此类设置。

不过，这些设置完全是自由形式的。如果没有他们的线索，我们就无法猜测哪些设置可能会做一些有用的事情。因此，再次重申，此时正确的做法是与他们交谈。