Git拉取失败，显示错误的包头。

Question

使用git pull命令时出现以下错误

remote: Counting objects: 146, done.
remote: fatal: unable to create thread: Resource temporarily unavailable
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header

有什么好办法可以成功地拉取（数据）吗？

- deimus

---

可能是Git存储库重打包失败的重复问题。 - Aleksandr Dubinsky

我也用 git subtree add 得到了这个。 - Sridhar Sarnobat

Answer 1

remote开头的行是在远程系统上运行git时的输出。错误信息：

fatal: unable to create thread: Resource temporarily unavailable

...强烈建议您的服务器已经耗尽了内存，这可能是由于以下原因之一造成的：

1. 具有大量大文件的存储库，这可能导致重新打包需要大量内存。
2. 虚拟内存受到限制-通常情况下或由于ulimit设置而仅针对该帐户

这里的建议是通过登录到远程系统（作为git运行的用户）并执行以下操作来限制打包所需使用的内存量：

git config --global pack.windowMemory "100m"
git config --global pack.packSizeLimit "100m"
git config --global pack.threads "1" 

- Mark Longair

---

谢谢！我遇到了与 OP 相同的错误。我尝试使用 pack.windowMemory 和 pack.SizeLimit 配置项，但仍然收到错误提示。 当我添加了 pack.threads "1" 后，问题得到解决！ - Brian C

我尝试从svn转换到git时充满了热情。但是一直遇到一些晦涩的问题，而这些问题的解决方法更加难以理解。我不确定转换的决定是否明智。 - René Nyffenegger

我遇到了一个问题，我改变了属性pack.SizeLimit而不是pack.packSizeLimit。这解决了我的问题。非常感谢！！！ - Stargazer

git config --global pack.windowMemory "100m" 解决了我的问题。 - Shadrack Kibet

Answer 2

补充@Mark Longair的回答：

我不得不运行以下命令来解决这个问题：

git config --global pack.windowMemory "100m"
git config --global pack.packSizeLimit "100m"
git config --global pack.threads "1" 
git config --global pack.deltaCacheSize "512m"

您可以在git文档git config中了解更多有关这些命令的信息。

- Wesley Gonçalves

---

这些参数的默认值是什么？ - RichWalt

根据我上面提到的文档页面，packSizeLimit 的默认值是 无限制，而 pack.deltaCacheSize 是 256 MiB。pack.threads 没有被提及，但它可能是 自动检测（与零相同）。但如果你想将它们设置为默认值，你可以从全局配置文件中简单地删除它们。 - Wesley Gonçalves

Answer 3

警告：如果您在使用 Git 2.19.1 时看到此错误，这是正常的，并且在 git-for-windows/git issue 1839 中有记录：“git gc 在计算对象的33％处崩溃”（对于git gc和也包括git pull都报告了 APPCRASH），因为“git pack-objects”中使用的互斥量未正确初始化，并导致“git repack”在Windows上出现核心转储。

如问题中所述：

It affects more than just gc. I hit a variant of it with pull too:

$ git pull
remote: Enumerating objects: 3548, done.
error: git upload-pack: git-pack-objects died with error.
fatremote: aborting due to possible repository corruption on the remote side.
al: git uploadf-pack: aborting due to possible repository corruption on the remote side.
atal: protocol error: bad pack header

这个问题已经在Git 2.20（2018年第4季度）中得到解决。
请参见提交 34204c8，提交 9308f45，提交 ce498e0（2018年10月16日），作者为Johannes Schindelin（dscho）。
^{（由Junio C Hamano -- gitster --于提交 620b00e合并，2018年10月30日）} “pack-objects”（mingw）：在正确的位置初始化“packing_data”互斥锁

在9ac3f0e（“pack-objects”：修复打包大型增量时的性能问题，2018年7月22日，Git v2.19.0-rc1）中引入了一个互斥锁，用于保护设置增量大小的调用。这个提交甚至添加了代码来初始化它，但是在错误的位置：在“init_threaded_search()”中，而调用“oe_set_delta_size()”（因此调用“packing_data_lock()”）可以发生在调用链“check_object()”<-“get_object_details()”<-“prepare_pack()”<-“cmd_pack_objects()”之前，这是在“prepare_pack()”函数调用“ll_find_deltas()”之前（该函数初始化了线程搜索）。

另一个表明互斥锁在错误位置初始化的迹象是，初始化它的函数位于内置目录下，而使用该互斥锁的代码则定义在“libgit.a”头文件中。

- VonC

---

可以检查那些 object_entry 的大小。 - VonC

Answer 4

我能够通过以下步骤解决这个问题：

第一步：使用较小的深度进行克隆

git clone https://your_git_clone_url --depth 3

第二步：编辑.git/config文件并添加develop行。由于设置了深度，因此无法切换到除master以外的远程分支，所以这是必需的。

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true
    symlinks = false
    ignorecase = true
[remote "origin"]
    url = https:<your git clone url>
    fetch = +refs/heads/master:refs/remotes/origin/master
    fetch = +refs/heads/develop:refs/remotes/origin/develop  <<--- Add this line
[branch "master"]
    remote = origin
    merge = refs/heads/master
[branch "develop"]
    remote = origin
    merge = refs/heads/develop

步骤3：使用fetch获取数据。

- prashant patankar