尝试了这里的大部分答案，我得到的错误与PUTTY SSH客户端与所有可能的星座。

一旦我切换到OpenSSH，错误就消失了(删除环境变量GIT_SSH并重新启动git bash)。

我用的是一台新机器和最新的git版本。在许多其他/旧机器上(AWS也是如此)，它在没有任何git配置的情况下使用PUTTY也能正常工作。

对我来说，当我把压缩改为 Git配置——global core.compression

这是

以前的回答建议设置为512m。我想说，有理由认为这在64位架构上是适得其反的。核心文档。packedGitLimit说:

缺省情况下，在32位平台上是256mib，在64位平台上是32tib(实际上是无限的)。这对于所有用户/操作系统都是合理的，除了最大的项目。您可能不需要调整这个值。

如果你想尝试一下，检查你是否设置了它，然后删除设置:

git config --show-origin core.packedGitLimit
git config --unset --global core.packedGitLimit

我也有同样的问题，我甚至试图直接从网站下载项目作为一个压缩文件，但下载被中断在完全相同的百分比。

这句话像魔法一样解决了我的问题

git config --global core.compression 0

我知道其他答案也提到了这一点，但是这里没有人提到这条线本身就可以解决问题。

希望能有所帮助。

几乎所有的答案都试过了，但运气不佳。最后，通过使用Github桌面应用程序https://desktop.github.com/，它成功了

带有M1芯片的Macbook /Monterey不确定这是否重要。

请注意，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.