Git pull 失败，包头错误

Git pull fails with bad pack header error

提问by deimus

git pull fails with following error

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

Any Ideas how to pull successfully ?

任何想法如何成功拉动？

回答by Mark Longair

The lines beginning with remoteare output from git running on the remote system. The error:

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

fatal: unable to create thread: Resource temporarily unavailable

... strongly suggests that you've run out of memory on the server, which can happen if you have either:

...强烈建议您已用完服务器上的内存，如果您有以下任一情况，则可能会发生这种情况：

1. A repository with lots of large files, which can cause re-packing to take a lot of memory.
2. Limited virtual memory - either in general, or just for that account due to the ulimitsetting

1. 包含大量大文件的存储库，这可能会导致重新打包占用大量内存。
2. 有限的虚拟内存 - 一般情况下，或由于ulimit设置而仅用于该帐户

A suggestion hereis to limit the amount of memory that packing may take by logging into the remote system (as the user that git runs as) and doing:

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

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

回答by VonC

Warning: if you see this error with Git 2.19.1, this is expected, and documented in git-for-windows/gitissue 1839: "git gccrashes at 33% of counting objects" (which reports an APPCRASH both for git gc, but alsofor git pull), because of a mutex used in "git pack-objects", which was not correctly initialized and caused "git repack" to dump core on Windows.

警告：如果您在 Git 2.19.1 中看到此错误，这是意料之中的，并记录在git-for-windows/git问题 1839 中：“git gc在计数对象的 33% 时崩溃”（报告了 APPCRASH 既 for git gc，也报告for git pull），因为使用了互斥锁在“git pack-objects”中，它没有正确初始化并导致“ git repack”在 Windows 上转储核心。

As mentioned in the issue:

正如问题中提到的：

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

$ 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

它影响的不仅仅是gc. 我也使用pull了它的一个变体：

$ 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

This is fixed in Git 2.20 (Q4 2018).
See commit 34204c8, commit 9308f45, commit ce498e0(16 Oct 2018) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster--in commit 620b00e, 30 Oct 2018)}

这已在 Git 2.20（2018 年第四季度）中修复。
请参阅Johannes Schindelin ( ) 的commit 34204c8、commit 9308f45、commit ce498e0（2018 年 10 月 16 日）。^{（由Junio C Hamano合并-- --在提交 620b00e 中，2018 年 10 月 30 日）}dscho
gitster

pack-objects(mingw): initialize packing_datamutex in the correct spot

In 9ac3f0e(pack-objects: fix performance issues on packing large deltas, 2018-07-22, Git v2.19.0-rc1), a mutex was introduced that is used to guard the call to set the delta size. This commit even added code to initialize it, but at an incorrect spot: in init_threaded_search(), while the call to oe_set_delta_size()(and hence to packing_data_lock()) can happen in the call chain check_object()<- get_object_details()<- prepare_pack()<- cmd_pack_objects(), which is long before the prepare_pack()function calls ll_find_deltas()(which initializes the threaded search).

Another tell-tale that the mutex was initialized in an incorrect spot is that the function to initialize it lives in builtin/, while the code that uses the mutex is defined in a libgit.aheader file.

pack-objects(mingw):packing_data在正确的位置初始化互斥锁

在9ac3f0e（pack-objects：修复打包大增量的性能问题，2018-07-22，Git v2.19.0-rc1）中，引入了一个互斥锁，用于保护设置增量大小的调用。这个提交甚至添加了初始化它的代码，但在一个不正确的地方： in 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()（它初始化线程搜索）。

互斥锁在不正确的位置初始化的另一个迹象是初始化它的函数位于 builtin/ 中，而使用互斥锁的代码在libgit.a头文件中定义。

回答by Wesley Gon?alves

Complementing the @Mark Longair's answer:

补充@Mark Longair的回答：

I had to run the following commands to fix this issue:

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

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

You can see more about these commands in the git documentation git config.

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

回答by prashant patankar

I was able to resolve this using following steps

我能够使用以下步骤解决此问题

Step 1. clone using lesser depth

步骤 1. 使用较小深度克隆

git clone https://your_git_clone_url--depth 3

git clone https://your_git_clone_url--depth 3

Step 2. Edit .git/config and add line for develop. This is required as after setting depth I was not able to switch remote branch other than master

步骤 2. 编辑 .git/config 并添加开发行。这是必需的，因为在设置深度后我无法切换 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

Step 3: get fetch

第 3 步：获取获取