请注意，Git 2.13.x/2.14(2017年第三季度)确实引发了默认核心。影响git取回的packedGitLimit: 在较大的平台上，默认的package -git限制值已经提高(从8 GiB提高到32 GiB)，以避免“gc”并行运行时“git获取”(可恢复的)失败。

参见David Turner (csusbdt)的commit be4ca29(2017年4月20日)。 帮助:Jeff King (peff)。 (由Junio C Hamano—gitster—在commit d97141b中合并，2017年5月16日)

Increase core.packedGitLimit When core.packedGitLimit is exceeded, git will close packs. If there is a repack operation going on in parallel with a fetch, the fetch might open a pack, and then be forced to close it due to packedGitLimit being hit. The repack could then delete the pack out from under the fetch, causing the fetch to fail. Increase core.packedGitLimit's default value to prevent this. On current 64-bit x86_64 machines, 48 bits of address space are available. It appears that 64-bit ARM machines have no standard amount of address space (that is, it varies by manufacturer), and IA64 and POWER machines have the full 64 bits. So 48 bits is the only limit that we can reasonably care about. We reserve a few bits of the 48-bit address space for the kernel's use (this is not strictly necessary, but it's better to be safe), and use up to the remaining 45. No git repository will be anywhere near this large any time soon, so this should prevent the failure.

就我而言，我只是升级了我的OpenSSL版本。旧版本的OpenSSL有漏洞，也没有可能需要的最新算法。截至今天，命令openssl version显示openssl 1.1.1f 31 Mar 2020。

首先，关闭压缩:

git config --global core.compression 0

接下来，让我们做一个部分克隆来截断下来的信息量:

git clone --depth 1 <repo_URI>

当它工作时，进入新目录并检索克隆的其余部分:

git fetch --unshallow 

或者,或者,

git fetch --depth=2147483647

现在，做一个常规的拉:

git pull --all

我认为在1.8版本中msysgit有一个小故障。x版本会加剧这些症状，因此另一种选择是尝试较早版本的git(我认为<= 1.8.3)。

从一个git克隆，我得到:

error: inflate: data stream error (unknown compression method)
fatal: serious inflate inconsistency
fatal: index-pack failed

重新启动我的机器后，我能够克隆回购罚款。

使用@cmpickle答案，我构建了一个脚本来简化克隆过程。

它托管在这里:https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

你可以使用下面的代码行运行它:

curl -sL https://git.io/JvtZ5 | sh -s repo_uri repo_folder

我也有同样的问题。遵循上面的第一步，我能够克隆，但我不能做任何其他事情。不能取、拉或结帐旧树枝。

每个命令运行得比平时慢得多，然后在压缩对象后终止。

I:\dev [master +0 ~6 -0]> git fetch --unshallow
remote: Counting objects: 645483, done.
remote: Compressing objects: 100% (136865/136865), done.

error: RPC failed; result=18, HTTP code = 20082 MiB | 6.26 MiB/s

fatal: early EOF

fatal: The remote end hung up unexpectedly

fatal: index-pack failed

这也发生在你的裁判使用太多内存的时候。修剪记忆为我解决了这个问题。只要给你取回的东西加上一个限制，比如->

git fetch --depth=100

这将获取历史记录中最近100次编辑的文件。 在此之后，您可以以正常速度执行任何命令。