致命：早期EOF致命：索引包失败

我已经用Google搜索了，发现了很多解决方案，但是没有一个适合我。

我正在尝试通过连接到LAN网络中的远程服务器从一台计算机克隆。
从另一台计算机运行此命令会导致错误。
但是在服务器上使用git：//192.168.8.5 ...运行SAME clone命令可以并成功。

有任何想法吗 ？

user@USER ~
$ git clone  -v git://192.168.8.5/butterfly025.git
Cloning into 'butterfly025'...
remote: Counting objects: 4846, done.
remote: Compressing objects: 100% (3256/3256), done.
fatal: read error: Invalid argument, 255.05 MiB | 1.35 MiB/s
fatal: early EOF
fatal: index-pack failed

我已经添加了此配置，.gitconfig但也没有帮助。
使用git版本1.8.5.2.msysgit.0

[core]
    compression = -1

首先，关闭压缩：

git config --global core.compression 0

接下来，让我们进行部分克隆以截断下降的信息量：

git clone --depth 1 <repo_URI>

在这种情况下，进入新目录并检索克隆的其余部分：

git fetch --unshallow 

或者，

git fetch --depth=2147483647

现在，进行常规拉动：

git pull --all

我认为1.8.x版本中的msysgit出现了故障，加剧了这些症状，因此另一种选择是尝试使用早期版本的git（我认为<= 1.8.3）。

git的内存需求可能会发生此错误。您可以将这些行添加到全局git配置文件（位于.gitconfig中$USER_HOME）中，以解决该问题。

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

终于解决了 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。

如@ingyhere所说：

浅克隆

首先，关闭压缩：

git config --global core.compression 0

接下来，让我们进行部分克隆以截断下降的信息量：

git clone --depth 1 <repo_URI>

在这种情况下，进入新目录并检索克隆的其余部分：

git fetch --unshallow

或者，

git fetch --depth=2147483647

现在，拉一下：

git pull --all

然后解决您的本地分支仅跟踪主站的问题

.git/config在您选择的编辑器中打开您的git配置文件（）

它说：

[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 fetch并git将立即拉出所有远程分支

就我而言，这非常有帮助：

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

这会将结帐仅限于提及的分支，因此将加快流程。

希望这会有所帮助。

我尝试了所有这些命令，但没有一个对我有用，但是有效的方法是将git_url更改为http而不是ssh

如果是clone命令，请执行以下操作：

git clone <your_http_or_https_repo_url> 

否则，如果您要使用现有存储库，请执行以下操作

git remote set-url origin <your_http_or_https_repo_url>

希望这对某人有所帮助！

当git内存不足时出现此错误。

释放一些内存（在这种情况下：让编译工作完成），然后再次尝试为我工作。

就我而言，这是一个连接问题。我连接到内部wifi网络，在该网络中，我对资源的访问受到限制。那是让git进行提取，但在特定时间它崩溃了。这意味着它可能是网络连接问题。检查一切是否运行正常：防病毒，防火墙等。

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

设置以下配置对我不起作用。

[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

先前的答案建议设置为512m。我会说有理由认为这在64位架构上适得其反。core.packedGitLimit的文档说：

在32位平台上，默认值为256 MiB；在64位平台上，默认值为32 TiB（实际上是无限量）。对于最大的项目以外的所有用户/操作系统，这应该是合理的。您可能不需要调整该值。

如果您想尝试一下，请检查是否已设置，然后删除该设置：

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

请注意，Git 2.13.x / 2.14（2017年第三季度）确实提高了默认设置core.packedGitLimit， 该默认设置会影响git fetch：
在更大的平台（从8 GiB到32 GiB）上提高了默认packed-git极限值，以git fetch防止发生“（可恢复）故障” “ gc”并行运行时。

请参阅David Turner（）的commit be4ca29（2017年4月20日）。 帮助：Jeff King（）。^{（通过合并JUNIOÇ滨野- -在提交d97141b，2017年5月16日）}csusbdt
peff
gitster

增加 core.packedGitLimit

如果core.packedGitLimit超过，git会关闭包。
如果与提取并行进行重新打包操作，则提取可能会打开一个包，然后由于击中packedGitLimit而被迫关闭它。
然后，重新打包可能会将包从获取中删除，导致获取失败。

增加core.packedGitLimit的默认值可防止这种情况。

在当前的64位x86_64机器上，可以使用48位地址空间。
看来64位ARM机器没有标准的地址空间量（即，它因制造商而异），而IA64和POWER机器具有完整的64位。
因此48位是我们可以合理考虑的唯一限制。我们为内核使用保留了48位地址空间中的几位（这不是严格必要的，但是最好是安全的），并最多使用剩余的45位。
任何时候git仓库都不会接近如此大很快，所以这应该可以防止失败。

使用@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文件，并在其末尾添加了以下几行：* hard fsize 1000000 * soft fsize 1000000

要实际“应用”新的限值，您需要重新登录

与切向相关，并且仅在您没有超级用户访问权限并从RPM（带有rpm2cpio）或其他包（.deb，..）中手动提取Git到子文件夹的情况下才有用。典型的用例：您尝试在企业服务器上使用较旧版本的Git。

如果git clone失败且fatal: index-pack failed 没有提早EOF提及，而是有关的帮助消息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

我有相同的错误日志，在ssh上使用git（v2.17.1）。就我而言，解决方案是：

1. 输入到我的服务器的git裸存储库。
2. 致电git gc。

请参阅git-gc文档：https : //git-scm.com/docs/git-gc。

例如：

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 clone git@my_server_url.com:my_repo_name

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

其他（黑客）解决方案是下载没有历史记录的最后一个主服务器：

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

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

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

git clone --depth 1“ ssh：.git” --branch“ specific_branch”

我关闭了同时进行的所有下载，这可能释放了一些空间并清理了上/下带宽

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 daemon”的各种修复。（稍后将ed15e58efe jk / daemon-fixes合并到maint中）。

我也有同样的问题。按照上述第一步，我可以克隆，但是我无能为力。无法获取，拉出或签出旧分支。

每个命令的运行速度都比平时慢得多，然后在压缩对象后死掉。

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

在这里尝试了大多数答案后，发现PUTTY SSH客户端具有所有可能的星座时均出现错误。

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

我正在使用一台新机器和最新的git版本。在许多其他/较旧的机器（也包括AWS）上，它在没有任何git配置的情况下也可以正常使用PUTTY。

我遇到了同样的问题。REPO太大，无法通过SSH下载。就像推荐的@ elin3t一样，我已经通过HTTP / HTTPS进行了克隆，并将.git / config中的REMOTE URL更改为使用SSH REPO。

我跑步时遇到以下相同的问题 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

我几乎尝试了这里提出的所有建议，但没有一个奏效。对我们来说，这个问题很气质，而且回购变得越大（在我们的Jenkins Windows build slave上），问题就变得越来越糟。

最终成为git使用的ssh版本。Git被配置为使用某些版本的Open SSH，该版本是通过core.sshCommand变量在用户.gitconfig文件中指定的。删除该行将其修复。我相信这是因为Windows现在附带了更可靠/兼容的SSH版本，默认情况下会使用它。

这对我有用，因为未指定标准名称服务器，所以设置了Google的名称服务器，然后重新启动网络：

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

从git克隆中，我得到：

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

重新启动计算机后，我可以克隆存储库了。

如果您使用的是Windows，则可能要检查git clone失败并显示“ index-pack”失败？。

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

有关更多信息，请参见此答案。

确保您的驱动器有足够的空间

这些都不适合我，但是使用Heroku的内置工具可以解决问题。

heroku git:clone -a myapp

此处的文档：https : //devcenter.heroku.com/articles/git-clone-heroku-app