小开

最佳答案

首先，关闭压缩:

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_url更改为http而不是ssh

如果是克隆命令做:

git clone <your_http_or_https_repo_url>

否则，如果你拉现有的回购，做它

git remote set-url origin <your_http_or_https_repo_url>

希望这能帮助到一些人!

小开

当git内存不足时，我得到了这个错误。

释放一些内存(在本例中:让编译作业完成)并再次尝试对我来说是可行的。

小开

在我的情况下，这是一个连接问题。我连接到一个内部wifi网络，在这个网络中，我只能访问有限的资源。这是让git进行取回，但在某个时间它崩溃了。这意味着它可能是网络连接问题。检查是否一切运行正常:防病毒，防火墙等

因此，elin3t的答案很重要，因为ssh提高了下载的性能，从而可以避免网络问题

小开

这对我来说很有效，设置谷歌的命名服务器，因为没有指定标准的命名服务器，然后重新启动网络:

sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0

小开

此错误可能发生在git的内存需求。为了解决这个问题，你可以将这些行添加到你的全局git配置文件中，即$USER_HOME中的.gitconfig。

[core]
packedGitLimit = 512m
packedGitWindowSize = 512m
[pack]
deltaCacheSize = 2047m
packSizeLimit = 2047m
windowMemory = 2047m

小开

在我的情况下，当协议是https时，什么都不起作用，然后我切换到ssh，并确保，我从上次提交而不是整个历史，以及特定的分支中拉回回购。这帮助了我:

Git克隆——深度1 "ssh:。Git "——branch " specific_branch "

小开

这些对我来说都没用，但使用Heroku的内置工具却奏效了。

heroku git:clone -a myapp

文档在这里:https://devcenter.heroku.com/articles/git-clone-heroku-app

小开

确保你的硬盘有足够的剩余空间

小开

从一个git克隆，我得到:

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

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

小开

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

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

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次编辑的文件。在此之后，您可以以正常速度执行任何命令

小开

注意，Git 2.13.x/2.14(2017年Q3)确实会引发默认的core.packedGitLimit，它会影响git fetch:
在较大的平台(从8gib到32gib)上，默认的打包git限制值已经提高，以在“gc”并行运行时，避免“git fetch”发生(可恢复的)失败

参见提交be4ca29 (20 Apr 2017) by 大卫·特纳(csusbdt) 得益于:杰夫·金(peff)。 ^{(由Junio C Hamano—gitster—在提交d97141b中合并，2017年5月16日)}

增加core.packedGitLimit

当core.packedGitLimit超过时，git将关闭包如果有一个重新打包操作与取回并行进行，则取回可能会打开一个包，然后由于packkedgitlimit被击中而被迫关闭它然后，重新打包可以从读取下删除包，导致读取失败
增加core.packedGitLimit的默认值来防止这种情况。

在当前64位x86_64机器上，48位地址空间可用 64位ARM机器似乎没有标准数量的地址空间(也就是说，它因制造商而异)，而IA64和POWER机器有完整的64位所以48位是我们唯一关心的极限。我们保留了48位地址空间中的一些位供内核使用(这不是严格的必要的，但最好是安全)，并使用剩余的45个短时间内不会有git存储库这么大，所以这应该可以防止失败

小开

如果你在Windows上，你可能想检查Git克隆失败&;index-pack&;失败了?。

基本上，运行git.exe daemon ...命令后，从控制台窗口选择一些文本。重试拉/克隆，它现在可能工作了!

更多信息请参见这个答案。

小开

对我来说，这很有帮助:

git clone --depth 1 --branch $BRANCH $URL

这将限制签出到只提到的分支，因此将加快过程。

希望这能有所帮助。

小开

在此期间，我关闭了所有正在进行的下载，这可能释放了一些空间，并清除了带宽

小开

最终由git config --global core.compression 9解决

来自BitBucket的问题线程: . >

我试了差不多五次，还是会这样。

然后我尝试使用更好的压缩，它工作!

git config --global core.compression 9

从Git文档:

core.compression 整数-1..9，表示默认压缩的水平。-1是zlib的默认值 0表示不压缩，1..9是各种速度/大小的权衡，9是最慢的如果设置，这将提供一个默认为其他压缩变量，如core.looseCompression 和pack.compression。

小开

git-daemon的问题似乎已经在v2.17.0中解决了(用一个不工作的v2.16.2.1验证)。例如，不再需要在控制台中选择文本以“锁定输出缓冲区”

从https://github.com/git/git/blob/v2.17.0/Documentation/RelNotes/2.17.0.txt:

对“git守护进程”的各种修复。 (稍后合并ed15e58efe jk/daemon-fixes进行维护).

小开

正如@ingyhere所说:

浅克隆

首先，关闭压缩:

git config --global core.compression 0

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

git clone --depth 1 <repo_URI>

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

git fetch --unshallow

或者,或者,

git fetch --depth=2147483647

现在，拉一下:

git pull --all

然后解决你本地分支只跟踪主的问题

在你选择的编辑器中打开git配置文件(.git/config)

上面写着:

[remote "origin"]
url=<git repo url>
fetch = +refs/heads/master:refs/remotes/origin/master

换线

fetch = +refs/heads/master:refs/remotes/origin/master

来

fetch = +refs/heads/*:refs/remotes/origin/*

做一个git取回和git将拉你所有的远程分支现在

小开

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

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

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

小开

我也遇到过同样的问题。REPO太大，无法通过SSH下载。就像@elin3t推荐的那样，我已经通过HTTP/HTTPS克隆了，并在. /配置中更改REMOTE URL以使用SSH REPO。

小开

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

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

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

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

小开

当我运行git pull时，我得到了与下面相同的问题

remote: Counting objects: 149, done.
Connection to git-codecommit.us-east-1.amazonaws.com closed by remote host.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

然后我检查了git status，有很多未提交的更改我通过承诺和推送所有未提交的更改修复了这个问题

小开

以上的解决方案对我都不起作用。

最终为我工作的解决方案是切换SSH客户端。 GIT_SSH环境变量设置为Windows Server 2019提供的OpenSSH。 7.7.2.1版

C:\Windows\System32\OpenSSH\ssh.exe

我简单地安装了腻子，0.72

choco install putty

并将GIT_SSH更改为

C:\ProgramData\chocolatey\lib\putty.portable\tools\PLINK.EXE

小开

下面的配置设置不适合我。

[core]
packedGitLimit = 512m
packedGitWindowSize = 512m
[pack]
deltaCacheSize = 2047m
packSizeLimit = 2047m
windowMemory = 2047m

正如前面的评论，这可能是git的内存问题。因此，我尽量减少工作线程(从32个减少到8个)，这样它就不会同时从服务器获取太多数据。然后我还添加了“-f”来强制同步其他项目

-f: Proceed with syncing other projects even if a project fails to sync.

那么现在可以正常工作了。

repo sync -f -j8

小开

我尝试了这里提出的所有建议，但没有一个奏效。对我们来说，这个问题是不稳定的，而且随着回购的规模越来越大(在Jenkins Windows构建奴隶上)，情况变得越来越糟。

它最终成为git使用的ssh版本。Git被配置为使用某个版本的Open SSH，在用户的.gitconfig文件中通过内核指定。sshCommand变量。把那条线拆了，它就固定了。我相信这是因为Windows现在提供了一个更可靠/兼容的SSH版本，默认使用。

小开

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

它驻留在这里:https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

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

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

小开

在我的例子中，问题不在于git配置参数，而是我的存储库中有一个文件超过了系统允许的最大文件大小。我可以检查它，试图下载一个大文件，得到一个“文件大小限制超过”;在Debian。

之后，我编辑了我的/etc/security/limits.conf文件，在它的末尾添加了以下几行:

硬fsize 1000000
软fsize 1000000

实际上“应用”;新的限制值需要重新登录

小开

与此相关，仅在没有根访问权限并手动从RPM(使用rpm2cpio)或其他包(.deb， ..)中提取Git到子文件夹时有用。典型的用例:您尝试在公司服务器上使用更新版本的Git而不是过时版本的Git。

如果git克隆失败，早期EOF提到fatal: index-pack failed , ，而不是关于usage: git index-pack的帮助消息，则版本不匹配，您需要使用--exec-path参数运行git:

git --exec-path=path/to/subfoldered/git/usr/bin/git clone <repo>

为了让这个自动发生，在你的~/.bashrc中指定:

export GIT_EXEC_PATH=path/to/subfoldered/git/usr/libexec

小开

这很令人困惑，因为Git日志可能会提示任何连接或ssh授权错误，例如:ssh_dispatch_run_fatal: Connection to x.x.x.x port yy: message authentication code incorrect， the remote end hung up unexpectedly， early EOF。

服务器端解决方案

让我们在服务器端优化git存储库:

进入我的服务器的git裸库。
git gc打电话。
叫git repack -A

例如:

ssh admin@my_server_url.com
sudo su git
cd /home/git/my_repo_name # where my server's bare repository exists.
git gc
git repack -A

现在我能够克隆这个存储库没有错误，例如在客户端:

git clone git@my_server_url.com:my_repo_name

命令git gc可以在git客户端调用，以避免类似的git push问题。

如果你是Gitlab服务的管理员，手动触发管家。它在内部调用git gc或git repack。

客户端解决方案

其他(黑客，仅客户端)解决方案是下载没有历史记录的上一个master:

git clone --single-branch --depth=1 git@my_server_url.com:my_repo_name

有可能不会发生缓冲区溢出。

小开

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

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

git config --global core.compression 0

我知道其他答案已经提到了这一点，但是，这里没有人提到这一行独自一人可以解决问题。

希望能有所帮助。

小开

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

小开

我得到相同的错误，在我这边，我通过运行这个命令来解决，在windows中它有一些内存问题

git config --global pack.windowsMemory 256m

小开

我在设置git缓冲区后尝试了几次，正如我在问题中提到的，现在似乎工作了。

所以如果你遇到这个错误，运行这个命令:

git config --global http.postBuffer 2M

然后再试几次。

参考:

git push error: RPC failed;result=56, HTTP code = 0

小开

网络质量很重要，尝试切换到不同的网络。帮助我的是把我的互联网连接从维珍媒体的高速陆地宽带换成了我手机上的热点

在此之前，我尝试了限制克隆大小的公认答案，尝试了在64位和32位版本之间切换，尝试了禁用git文件缓存，没有一个有用。

然后我通过我的手机切换到连接，第一步(git克隆-depth 1 <repo_URI>)成功了。切换回我的宽带，但下一步(git fetch -unshallow)也失败了。所以我删除了到目前为止克隆的代码，切换到移动网络，再次尝试默认的方式(git clone <repo_URI>)，它成功了，没有任何问题。

小开

虽然不是完全相同的设置，但我在Ubuntu 20.04上挂载nfs共享时遇到了这个问题。我还没有找到任何解决方案，所以我分享了我是如何解决的，希望我能帮助到别人。

错误消息是(有时带有/没有警告):

warning: die() called many times. Recursion error or racy threaded death!
fatal: premature end of pack file, 29 bytes missing
fatal: premature end of pack file, 24 bytes missing
fatal: index-pack failed

Git浅克隆，禁用压缩等并没有解决这个问题。

当我用nfsvers=4.2而不是nfsvers=4.0挂载共享时，问题消失了。

小开

我在macOS大苏尔M1芯片上遇到了这个问题，没有一个解决方案对我有效。

编辑:作为M2芯片的解决方案，以及。

我通过增加下面的ulimit来解决它。

ulimit -f 2097152
ulimit -c 2097152
ulimit -n 2097152

运行上面的命令只对当前终端会话有效，所以首先运行这个命令，然后克隆存储库。

小开

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

这是

小开

只是在这里添加一个提示，如果你的git克隆命令有一个代理参数，你的代理服务器可能会过早地断开你的http/s请求，因为它自己的配置不允许太大的http响应二进制。仅供参考。

小开

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

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

小开

连接的问题

这是最有可能的原因。特别是如果你的git是最新的。(你可以更新你的git，如果不是最新的)

1-检查连接为稳定的 2 - VPN =比;禁用它(如果使用=>大罪魁祸首)  3-杀毒软件;防火墙

VPN VPN VPN =>大罪魁祸首

Git缓存，缓冲区，内存和压缩

其他答案很好地涵盖了这一点。

会用https://stackoverflow.com/a/29355320/7668448

使用实例使用cli打开全局配置。

git config --global -e

如果没有，则:

https://stackoverflow.com/a/22317479/7668448 < a href = " https://stackoverflow.com/a/22317479/7668448 " > < / >

fatal:早期EOF fatal:索引包失败

增加`core.packedGitLimit`

连接的问题

Git缓存，缓冲区，内存和压缩

fatal:早期EOF fatal:索引包失败

增加core.packedGitLimit

连接的问题

Git缓存，缓冲区，内存和压缩

增加`core.packedGitLimit`