挂在“ POST git-Receip-pack (chunked)”上

老实说，我对 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分钟了。我猜是挂起来了，但是... 我能做点什么找出原因吗？

67495 次浏览
小开

可能是您的凭证。使用 git + ssh 协议而不是 https。

小开
最佳答案

这是 Git 中的一个 bug; 当使用 HTTPS 时，它会对超过一定大小的上传使用分块编码。那些不管用。

一个简单的修复方法是告诉 git 不要进行块处理，直到出现一些大得离谱的值，例如:

git config http.postBuffer 524288000
小开

如果你发现这个网站是因为 BitBucket 错误地显示了错误信息，那么查看下面这个问题的答案:

特别是 尼古拉斯 · 皮克林和 Simon Tewsi关于键的哪个部分需要粘贴到 BitBucket 对话框的评论。

小开

使用 SourceTree 推送到 BitBucket，我每隔几个月就会遇到一次这样的错误。结果我只需要再等五分钟，它就自己解决了。它看起来已经挂起来，诱惑就是取消，再试一次，但也许再坚持一会儿。我知道这个问题已经得到了回答，但是我的提交量可能只有几百 kb，而不是原来海报上所说的40mb。

小开

使用 Git 2.13(2017年第二季度) ，您将能够将 http.postBuffer设置为一个非常大的数字(即，在某些平台上大于 ulong)。

见 第37季，第680集(2017年4月11日) by 大卫 · 特纳(csusbdt)。
(由 朱尼奥 · C · 哈马诺 gitster于2017年4月24日在 犯罪现场调查，第四季，第1集合并)

允许全范围的 ssize_t值

不幸的是，为了推出一些大型回购服务器做 不支持分块编码，http postbuffer有时必须 超过2G。
在64位系统上，这是可以的: 我们只是 malloc 一个更大的缓冲区。

这意味着我们需要使用 CURLOPT _ POSTFIELDSIZE _ LARGE 来设置 缓冲区大小。

因此，Git 2.34(Q42021)放弃了对 cURL 库古老版本(pre 7.19.4)的支持:

见 提交644de29，犯罪现场调查，第十三季，第7集，提交1119A15(2021年7月30日) by 杰夫 · 金(peff)。
见 提交8dda4cb，提交5db9d38(2021年7月30日) by 埃瓦尔 · 阿恩菲尔 · 比亚马森(avar)。
(由 朱尼奥 · C · 哈马诺 gitster合并于 提交 e48a623,2021年8月24日)

http : 对旋度 < 7.11.1的下拉支持

签名: Jeff King
埃瓦尔 · 阿恩夫约尔 · 比亚马森

放弃对这个古老版本的 curl 的支持，并通过让我们去掉一些“ # ifdef”来简化代码。

由于我们在 37ee680中使用了 CURLOPT_POSTFIELDSIZE(“ http.postbuffer: 允许 ssize_t值的全部范围”，2017-04-11，Git v2.13.0-rc1—— 合并) ，所以 Git 不会使用超过7.11.1的香草卷曲来构建。
这个字段是在 curl 7.11.1中引入的。

我们可以用更多的 #ifdefs来解决这些编译问题，但是不值得这么麻烦。
版本7.11.1在2004年3月发布，已经超过17年了。
让我们声明它太旧，并放弃任何现有的 ifdefs，回到更早的时候。
一个明显的好处是，我们将有更少的条件位杂乱的代码。

这个补丁删除了所有引用旧版本的 #ifdefs(注意 curl 的预处理器宏是十六进制的，所以我们要找的是070b01，而不是071101)。


提交答案