git推送到远程错误：远程：警告：由于文件太多，已跳过不精确的重命名检测

在我的机器上完成释放后<代码>git flow发行版完成“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配置文档。根据我读到的内容，我在配置中设置了这些值

$ 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.rename

默认为

true

，但当我查看配置时，它不存在，这就是我添加

副本的原因

这是我的完整配置文件，以防有帮助

[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

在
git推送过程中看到的任何消息（前缀为
remote:
）都不是来自您的git，而是来自他们的git。您在自己的存储库中所做的任何设置都不会影响它。1

如果他们是接收您的
git-push的“他们”
-有一个正常的日常存储库，您的
master
的
git-push将向他们发送您的提交，并要求他们设置其
master
，以识别与您的
master
相同的提交。要么立即成功（因为您要求他们设置的提交是他们已经作为
主控
进行的提交的后代），要么立即失败（因为不是这样）

因此，我们可以得出这样的结论：无论他们是谁，当您的
git push
请求他们的git更新他们的
master
时，他们都幻想自己的存储库运行一些特殊操作。他们的这个特殊操作现在正在运行，并执行某种
gitdiff
命令。（该操作可能是通过Git钩子执行的，例如预接收或更新钩子。）

这是他们的Git需要调整其重命名限制，以处理。。。嗯，我们不知道他们在做什么！我们只知道它们正在运行
git diff
！所以这是我们必须猜测的点。他们可以做一些合理的事情，还有更多不合理的事情

他们几乎肯定在做：

git diff <hash1> <hash2>

git-diff

hash1
值可能是其
主文件的当前值。如果是这样的话，您可以运行
git fetch
（甚至只运行
git ls remote
）来查看它们的
主机所代表的哈希ID。
hash2
值可能是存储库中您称之为
master
的提交的哈希ID，在这种情况下，您可以使用自己的名称
master

如果我们所有的猜测都正确，并且正确地猜测了他们在配置中设置的任何设置，那么我们可能能够重现他们的预接收或更新挂钩中出现的任何错误

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

此时，正确的做法是询问他们正在做什么，为什么要这样做，以及您是否可以以某种方式为他们改进。如果这样做失败了，那么就走上这条半死胡同，猜测他们在做什么，为什么，以及你是否能够和如何克服他们的错误


1现代Git实际上有一种方法，可以在推送Git时将特定的
变量=值
设置从一个Git发送到另一个Git。默认情况下，这些选项对接收Git没有任何影响，因为否则您就可以使用这些选项欺骗现有的、未经设置的Git接收者。但我们知道他们使用的是某种脚本，来自Git钩子；这个脚本实际上可能会查找这样的设置

不过，这些设置完全是自由形式的。如果没有他们的一些线索，我们就无法猜测哪些设置可能会做一些有用的事情。因此，再次强调，此时正确的操作是与他们交谈。
我认为可能是因为错误来自“远程”。这是我们的GitHub企业服务器。我能控制它。但我找不到可以在上面配置这些限制的位置。对不起，这么短，走出办公室。然后你可以确保你的钩子做正确的事情。您可以在服务器上的实际存储库中配置它：登录，
cd
到存储库路径，运行
git config
。如果有一些恼人的web界面阻碍了我，那就想办法解决它，或者绕过它。我确实有一个预接收钩子，可以执行
git diff
。我将禁用它，然后再次运行这个过程，看看会发生什么。如果这是罪魁祸首，那么我可以在进行大型发布时禁用钩子，但我更希望了解如何在企业服务器上调整这些设置（如果可能的话）。禁用预接收钩子后，错误就消失了。
git diff <hash1> <hash2>