Question

在计算机上完成发行后……git flow release finish 'X.X.XXX.X'然后，我必须将新发行版推入原始版本。所以我运行这些命令...

$ 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:前缀的消息不是来自 your Git，而是来自他们的 Git。您在自己的存储库中所做的任何设置都不会影响它。¹

如果他们（无论是谁来接收您的git push）拥有正常的日常存储库，则您的git push中的master会将他们的提交发送给他们，并要求他们设置其master以标识与您的master相同的提交。要么立即成功（因为您已要求他们设置的提交是他们已经成为master的提交的后代），要么立即失败（因为没有）。

因此，我们可以得出结论，无论您是谁，无论您的git push要求其Git更新其master时，无论他们是谁，他们都想尽其所能执行某些特殊操作。他们的特殊动作现在正在运行，并且正在执行某种git diff命令。（该操作可能是通过Git钩子完成的，例如预先接收或更新钩子。）

这是其 Git，需要对其重命名限制进行调整，以处理...之间的区别……好吧，我们不知道 {{1 }} -ing！我们只知道他们正在运行git diff！因此，这是我们必须猜测的点。他们可以做一些合理的事情，还有更多不合理的事情。

他们几乎肯定在做：

git diff

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

如果我们对所有猜测正确无误，并且还正确猜测了在其配置中设置的他们的任何设置，则我们可能能够重现出任何问题在他们的预先接收或更新挂钩中。

当然，仅仅能够复制它并不能使我们对其进行修复。实际上，只有他们可以修复。充其量，我们可以通过推送不同的提交来解决它。

这时正确的行动是询问他们在做什么，为什么这样做以及您是否可以通过某种方式为他们改善这种情况。如果失败了，那么然后走到这个半盲巷，猜测他们在做什么，为什么，以及是否以及如何解决他们的错误。

¹现代Git实际上有一种方法可以在master期间将特定的variable = value设置从一个Git发送到另一个。默认情况下，这些对接收Git根本不起作用。否则，您可以使用这些选项来欺骗现有的，初始设置的Git接收器。但是我们知道他们正在从Git钩中使用某种脚本。该脚本可能实际上会查找此类设置。

这些设置是完全自由格式的。没有他们的线索，我们无法猜测什么设置可能会做一些有用的事情。因此，再次正确的做法是与他们交谈。

git push to remote错误：remote：警告：由于文件过多，跳过了不正确的重命名检测

1 个答案: