挂起于“POST git-receive-pack(分块)”

7uzetpgm 于 2022-12-25 发布在 Git

关注(0)|答案(6)|浏览(123)

老实说，我对git的内部结构知之甚少。
我已经暂存并提交了一个40mb的目录，但是当我开始推送时...

$ git push --verbose --progress
Pushing to https://acron0@bitbucket.org/acron0/project.git
Password for 'https://acron0@bitbucket.org':
POST git-receive-pack (chunked)

像这样已经20分钟了。我想它是挂着的，但是......我能做些什么来找出原因吗？

Git

来源：https://stackoverflow.com/questions/10790232/hanging-at-post-git-receive-pack-chunked

6条答案

按热度按时间

sshcrbum1#

这是Git中的一个bug;当使用HTTPS时，它会对超过一定大小的上传文件使用分块编码。2那些不起作用。
一个简单的修正是告诉git不要分块直到某个大到离谱的size值，比如：

git config http.postBuffer 524288000

赞(0）回复(0）举报 2022-12-25

ttcibm8c2#

可能是您的凭据，使用git+ssh协议代替https。

赞(0）回复(0）举报 2022-12-25

esbemjvw3#

使用SourceTree推送到BitBucket时，我每隔几个月就会遇到一次这样的错误。结果是，我只需要多等5分钟，它就会自己排序。它看起来像挂了一样，诱惑是取消并重试，但可能会坚持更长时间。我知道这个问题已经得到了回答，但我的承诺可能只有几百KB，而不是最初的海报所说的40MB。

赞(0）回复(0）举报 2022-12-25

rhfm7lfc4#

在Git 2.13（Q2 2017）中，你可以将http.postBuffer设置为一个非常大的数字（例如，在某些平台上大于ulong）。
参见David Turner ( csusbdt )（2017年4月11日）。
（由Junio C Hamano -- gitster --合并至commit 4c01f67，2017年4月24日）

`http.postbuffer`：允许`ssize_t`值的全范围

不幸的是，为了在服务器不支持分块编码的地方推送一些大型repos，http postbuffer有时必须超过2GB。
在64位系统上，这是可以的：我们只分配一个更大的缓冲区。
这意味着我们需要使用CURLOPT_POSTFIELDSIZE_LARGE来设置缓冲区大小。
因此，Git 2.34（Q4 2021）不再支持cURL库的旧版本（7.19.4之前的版本）：
参见commit 644de29、commit 013c7e2、commit 1119a15（2021年7月30日），作者为Jeff King ( peff )。
参见commit 8dda4cb、commit 5db9d38（2021年7月30日）和Ævar Arnfjörð Bjarmason ( avar )。
（由Junio C Hamano -- gitster --合并至commit e48a623，2021年8月24日）

`http`： curl 跌落支持〈7.11.1

签署人：杰夫·金
签署人：埃瓦尔·阿恩菲约德·比亚尔马森
放弃对这个古老版本的curl的支持，并通过允许我们去掉一些“#ifdef”来简化代码。
Git将不会使用早于7.11.1的vanilla curl构建，因为我们在37ee680中使用了CURLOPT_POSTFIELDSIZE（“http.postbuffer：允许ssize_t值的完整范围”，2017年4月11日，Git v2.13.0-rc 1--merge）。
这个字段是在curl 7.11.1中引入的。
我们可以用更多的#ifdefs来解决这些编译问题，但不值得这么麻烦。
版本7.11.1于2004年3月发布，距今已有17年多。
让我们声明它太旧，并删除任何现有的更早的ifdefs。
一个明显的好处是，我们将有更少的条件位来扰乱代码。
这个补丁删除了所有引用旧版本的#ifdefs（注意curl的预处理器宏是十六进制的，所以我们要查找070 b 01，而不是071101）。