fatal: early EOF fatal: index-pack failed
我在谷歌上找到了很多解决方案，但没有一个适合我。
我正试图通过连接到局域网中的远程服务器从一台机器上进行克隆。从另一台计算机运行此命令会导致错误。但使用git://192.168.8.5运行相同的克隆命令…在服务器上，一切都很顺利。
有什么想法吗？
1 2 3 4 5 6 7 8 | 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 |
我在
1 2 | [core] compression = -1 |
号
首先，关闭压缩：
1 | git config --global core.compression 0 |
接下来，让我们做一个部分克隆来截断下面的信息量：
1 | git clone --depth 1 <repo_URI> |
号
如果可以，请进入新目录并检索克隆的其余部分：
1 | git fetch --unshallow |
或者，交替地，
1 | git fetch --depth=2147483647 |
。
现在，定期拉一下：
1 | git pull --all |
我认为msysgit在1.8.x版本中有一个小故障，会加重这些症状，所以另一个选择是尝试使用早期版本的git(<=1.8.3，我认为)。
对于Git的内存需求，可能会发生此错误。您可以将这些行添加到全局Git配置文件中，即
1 2 3 4 5 6 7 | [core] packedGitLimit = 512m packedGitWindowSize = 512m [pack] deltaCacheSize = 2047m packSizeLimit = 2047m windowMemory = 2047m |
。
最终由
从BitBucket问题线程：
I tried almost five times, and it still happen.
Then I tried to use better compression and it worked!
git config --global core.compression 9
号
从Git文档：
core.compression
An integer -1..9, indicating a default compression
level. -1 is the zlib default.
0 means no compression, and 1..9 are
various speed/size tradeoffs, 9 being slowest.
If set, this provides a
default to other compression variables, such as core.looseCompression
and pack.compression.
号
如@ingyhere所说：
浅克隆
首先，关闭压缩：
1 | git config --global core.compression 0 |
接下来，让我们做一个部分克隆来截断下面的信息量：
1 | git clone --depth 1 <repo_URI> |
号
如果可以，请进入新目录并检索克隆的其余部分：
1 | git fetch --unshallow |
或者，交替地，
1 | git fetch --depth=2147483647 |
。
现在，拉一下：
1 | git pull --all |
那么解决你当地分支机构唯一的跟踪主
在您选择的编辑器中打开Git配置文件(
上面写着：
1 2 3 | [remote"origin"] url=<git repo url> fetch = +refs/heads/master:refs/remotes/origin/master |
。
更改线条
1 | fetch = +refs/heads/master:refs/remotes/origin/master |
。
到
1 | fetch = +refs/heads/*:refs/remotes/origin/* |
做一个git获取，git将立即提取所有远程分支
当Git内存不足时，我得到了这个错误。
释放一些内存(在本例中是：让编译任务完成)，然后再试一次对我来说很有效。
在我的例子中，这是非常有帮助的：
1 | git clone --depth 1 --branch $BRANCH $URL |
号
这将只将签出限制在所提到的分支，因此将加快进程。
希望这会有所帮助。
我尝试了所有这些命令，但没有一个对我有效，但有效的是将git-url改为http-ssh
如果是克隆命令，请执行：
1 | git clone <your_http_or_https_repo_url> |
。
否则，如果你正在进行现有回购，就用
1 | git remote set-url origin <your_http_or_https_repo_url> |
。
希望能帮上忙！
在我的例子中，这是一个连接问题。我连接到一个内部WiFi网络，在那里我对资源的访问有限。那是让吉特去拿东西，但在某个时候它坏了。这意味着它可能是一个网络连接问题。检查是否一切正常运行：防病毒、防火墙等。
因此，elin3t的答案很重要，因为ssh提高了下载性能，从而避免了网络问题。
请注意，Git 2.13.x/2.14(2017年第3季度)确实提高了影响
见David Turner(
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.
号
以前的答案建议设置为512M。我认为有理由认为这会对64位体系结构产生反作用。core.packedgitlimit的文档显示：
Default is 256 MiB on 32 bit platforms and 32 TiB (effectively unlimited) on 64 bit platforms. This should be reasonable for all users/operating systems, except on the largest projects. You probably do not need to adjust this value.
号
如果要尝试，请检查是否已设置，然后删除设置：
1 2 | git config --show-origin core.packedGitLimit git config --unset --global core.packedGitLimit |
。
在我的例子中，当协议是https时，没有任何工作，然后我切换到ssh，并确保从上一次提交中提取repo，而不是整个历史，以及特定的分支。这对我有帮助：
git clone--深度1"ssh:.git"--分支"特定分支"
确保您的驱动器有足够的空间
我也有同样的问题。按照上面的第一步，我可以克隆，但我不能做任何其他事情。无法提取、拉动或签出旧的分支。
每个命令的运行速度都比平时慢得多，然后在压缩对象后死亡。
1 2 3 4 5 6 7 8 9 10 11 | 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 |
号
当你的裁判占用了太多的内存时，也会发生这种情况。修剪记忆为我修复了这个。只需对您获取的内容添加一个限制就可以了，所以->
1 | git fetch --depth=100 |
号
这将获取文件，但在其历史记录中最后100次编辑。在这之后，你可以做任何命令，只是在正常速度。
当我运行
1 2 3 4 5 | 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守护进程问题似乎已在2.17.0版中解决(已使用不工作的2.16.2.1版进行验证)。也就是说，不再需要在控制台中选择文本以"锁定输出缓冲区"。
从https://github.com/git/git/blob/v2.17.0/documentation/relnotes/2.17.0.txt：
- Assorted fixes to"git daemon".
(merge ed15e58efe jk/daemon-fixes later to maint).
号
尝试了这里的大多数答案，我得到了putty ssh客户机所有可能的星座的错误。
切换到openssh后，错误就消失了(删除环境变量git_ssh并重新启动git bash)。
我使用的是一台新机器和最新的Git版本。在许多其他/旧的机器上(同样是AWS)，它也可以在没有任何Git配置的情况下，使用Putty按预期工作。
我也遇到过同样的问题。回购协议太大，无法通过ssh下载。正如@elin3t推荐的那样，我已经通过http/https克隆了它，并在.git/config中更改了远程URL以使用ssh repo。
这些都不适合我，但是使用Heroku的内置工具就成功了。
1 | heroku git:clone -a myapp |
文档：https://devcenter.heroku.com/articles/git-clone-heroku-app
如果您在Windows上，您可能希望检查git clone是否失败，以及"index pack"是否失败？.
基本上，在运行
有关详细信息，请参阅此答案。
这对我很有效，因为没有指定标准名称服务器，所以设置了Google名称服务器，然后重新启动网络：
1 | sudo echo"dns-nameservers 8.8.8.8">> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0 |
从一个Git克隆中，我得到：
1 2 3 | error: inflate: data stream error (unknown compression method) fatal: serious inflate inconsistency fatal: index-pack failed |
。
重新启动机器后，我可以克隆repo fine。