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

时间：2014-01-22 08:32:18

标签： git cygwin msysgit

我用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

36 个答案:

答案 0 :(得分：416)

首先，关闭压缩：

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（我认为＆lt; = 1.8.3）。

答案 1 :(得分：77)

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

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

答案 2 :(得分：12)

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

解决

From a BitBucket issue thread:

  

我差不多尝试了五次，但仍然会发生。

     

然后我尝试使用更好的压缩效果！

     

git config --global core.compression 9

From the Git Documentation:

  

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

答案 3 :(得分：7)

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

答案 4 :(得分：5)

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

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

答案 5 :(得分：5)

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

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

这会将结帐限制为仅提及分支，因此会加快处理速度。

希望这会有所帮助。

答案 6 :(得分：4)

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

如果是clone命令：

git clone <your_http_or_https_repo_url>

否则，如果您要使用现有的回购，请使用

git remote set-url origin <your_http_or_https_repo_url>
希望这有助于某人！

答案 7 :(得分：4)

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

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

答案 8 :(得分：3)

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

[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

答案 9 :(得分：1)

请注意，Git 2.13.x / 2.14（2017年第3季度）会提高影响core.packedGitLimit的默认git fetch：
默认的packed-git限制值已在较大的平台上提升（从8 GiB到32 GiB ）以保存＆＃34; git fetch＆＃34;来自（可恢复的）失败，而＃34; gc＆＃34;正在并行运行。

commit be4ca29见David Turner (csusbdt)（2017年4月20日） 帮助：Jeff King (peff)。
（2017年5月16日Junio C Hamano -- gitster -- commit d97141b合并）

  

增加core.packedGitLimit

     

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

     

增加core.packedGitLimit的默认值以防止此情况发生。

     

在当前的64位x86_64计算机上，可以使用48位地址空间   似乎64位ARM机器没有标准数量的地址空间（也就是说，它因制造商而异），IA64和POWER机器具有完整的64位。   所以48位是我们可以合理关注的唯一限制。我们保留了一些48位地址空间用于内核的使用（这不严格   必要的，但最好是安全的），并使用剩余的45   没有任何git存储库可以在任何时间附近的任何地方，所以这应该可以防止失败。

答案 10 :(得分：1)

这令人困惑，因为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存储库：

  1. 输入服务器的git裸存储库。
  2. 致电git gc。
  3. 致电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客户端调用命令git gc，以避免类似的git push问题。

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

客户端解决方案

其他（仅限于客户端的hack）解决方案正在下载没有历史记录的最后一个master：

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

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

答案 11 :(得分：1)

切线相关，仅在没有root用户访问权限并且从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

答案 12 :(得分：1)

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

  

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

如果要试用，请检查是否已设置，然后删除设置：

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

答案 13 :(得分：1)

在我的情况下，问题不是git配置参数，而是我的存储库中有一个文件超出了系统上允许的最大文件大小这一事实。我能够检查它，以尝试下载大文件并在Debian上获得“超出文件大小限制”。

此后，我编辑了/etc/security/limits.conf文件，并在文件末尾添加了以下几行：

  • hard fsize 1000000
  • soft fsize 1000000

要真正“应用”新的极限值，您需要重新登录

答案 14 :(得分：1)

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

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

您可以使用以下行来运行它：

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

答案 15 :(得分：0)

我在设置git buffer后尝试了好几次，就像我在问题中提到的那样，现在看来可以了。

因此，如果遇到此错误，请运行以下命令：

git config --global http.postBuffer 2M

，然后再试几次。

参考：

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

答案 16 :(得分：0)

我遇到了同样的错误， 在我这边，我通过运行此命令解决了此问题，在Windows中它存在一些内存问题。

git config --global pack.windowsMemory 256m

答案 17 :(得分：0)

网络质量很重要，请尝试切换到其他网络。 是什么帮助我将Internet连接从Virgin Media高速陆地宽带更改为手机上的热点。

在我尝试接受可接受的答案以限制克隆大小，尝试在64位和32位版本之间切换，尝试禁用git文件缓存之前，它们都没有帮助。

然后我通过手机切换到连接，第一步（git clone --depth 1 ）成功。切换回我的宽带，但是下一步（git fetch --unshallow）也失败了。因此，我删除了到目前为止已克隆的代码，切换到移动网络后再次尝试使用默认方式（git clone ），并且成功完成，没有任何问题。

答案 18 :(得分：0)

就我而言，我只是升级了OpenSSL版本。较旧的OpenSSL版本具有漏洞，也没有可能需要的最新算法。从今天开始，命令openssl version显示 OpenSSL 1.1.1f 2020年3月31日。

答案 19 :(得分：0)

虽然不完全相同的设置，但我在 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 安装共享时，问题消失了。

答案 20 :(得分：0)

我遇到了同样的问题，我什至尝试直接从网站以zip文件的形式下载该项目，但是下载的中断率完全相同。

这行代码像魅力一样解决了我的问题

git config --global core.compression 0

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

希望有帮助。

答案 21 :(得分：0)

以下步骤非常适合我。

enter image description here

git clone --depth 1 https://github.com/user/rep.git

答案 22 :(得分：0)

我在使用 macOS Big Sur M1 芯片时遇到了这个问题，但没有一个解决方案适合我。

我通过增加下面的 ulimits 解决了这个问题。

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

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

答案 23 :(得分：0)

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

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

答案 24 :(得分：0)

以上所有解决方案都不适合我。

最终对我有用的解决方案是切换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

答案 25 :(得分：0)

运行- hosts: localhost connection : local become: yes become_user: root

时遇到与以下相同的问题 
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 ，其中有很多未提交的更改 我通过提交并推送所有未提交的更改来解决此问题。

答案 26 :(得分：0)

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

答案 27 :(得分：0)

在这里尝试了大多数答案，我得到了 PUTTY SSH客户端和所有可能的星座的错误。

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

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

答案 28 :(得分：0)

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稍后修复）。
    •   

答案 29 :(得分：0)

我关闭了我在此期间所做的所有下载，这可能会释放一些空间并清除/减少带宽

答案 30 :(得分：0)

我有同样的问题。在上面的第一步之后，我能够克隆，但我不能做任何其他事情。无法获取，拉取或结帐旧分支。

每个命令运行速度比平常慢得多，然后在压缩对象后死亡。

 public YourViewModel()
{
        Models.ComboboxItem item = new Models.ComboboxItem();
        item.Text = "Con sonoro";
        item.Value = 0;
        _notificationMode.Add(item);
}

当您的ref使用太多内存时也会发生这种情况。修剪内存为我修复了这个问题。只需为您提取的内容添加限制 - ＆gt; 

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

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

答案 31 :(得分：0)

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

答案 32 :(得分：0)

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

git clone --depth 1＆＃34; ssh：.git＆＃34; --branch“specific_branch”

答案 33 :(得分：-1)

如果您使用的是Windows，则可能需要查看git clone fails with "index-pack" failed?。

基本上，在运行/var/log/mongodb/ sudo chown -R mongodb:mongodb . /var/lib/mongodb/ sudo chown -R mongodb:mongodb . /stack/mongodb/tmp/ sudo chown mongodb mongodb-27017.sock $/ ps -ef | grep mongo {get for mongo PID} $/ kill -9 PID $/ sudo service mongodb start 命令后，从该控制台窗口中选择一些文本。重试拉/克隆，它现在可能正常工作！

有关详细信息，请参阅this answer。

答案 34 :(得分：-1)

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

heroku git:clone -a myapp

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

答案 35 :(得分：-1)

这对我有用，设置谷歌名称服务器，因为没有指定标准名称服务器，然后重新启动网络：

sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0
相关问题
最新问题