logo标签列表

卡在“POST git-receive-pack（分块）”

gitversion-controlbitbucket
82

坦白说，我对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分钟了。我猜它卡住了，但是...有什么办法可以查找原因吗？

我有同样的问题，同样的错误信息，sourcetree和github最终会冻结和崩溃。我尝试了下面建议的命令，现在它显示类似的内容：“POST git-receive-pack ({一些9位数})”。 - RaenirSalazar
我不得不更新我的Git版本。https://dev59.com/xIvda4cB1Zd3GeqPfea2#30842134 - Mark
始终值得检查状态页面 - 我刚刚无法推送新存储库，发现BitBucket SSH已经停止... - William Turrell
6个回答
160

这是 Git 中的一个 bug；当使用 HTTPS 时，对于超过一定大小的上传，它将使用分块编码，但这些上传不起作用。

一个简单的解决方法是告诉 Git 不要分块，直到达到某个荒谬地大的大小值，例如：

git config http.postBuffer 524288000
2
在Git v1.9.5.msysgit.1中仍然在Windows上挂起。 - spankmaster79
4
设置postBuffer也没有帮助我，但是根据https://dev59.com/xIvda4cB1Zd3GeqPfea2#30842134中的建议，升级到Git for Windows的预发布版本解决了我的问题。 - bdukes
12
这个错误是因为ngix被配置为拒绝大文件，所以除了添加更大的缓冲区外，您应该将它放在您的服务器接受的范围内（在我的情况下是nix默认配置）。git config http.postBuffer 5242 应该分成大约5k块。 - tyoc213
2
在我的情况下，我不得不将帖子缓冲区大小减小到5000，正如@tyoc213所指出的那样。 - Vadim Kirilchuk
2
顺便说一下，最终的“好”方法应该是将您的用户的远程公钥添加到GitLab中，以便启用SSH而不是HTTPS，这样它就可以处理大文件了（除非像GitHub一样的服务器根据策略拒绝它们，我猜在未来/现在会这样做）。 - tyoc213
显示剩余3条评论
22

可能是你的凭证问题。建议使用 git+ssh 协议而非 https。

1
对我也起作用了。有什么想法为什么它不能使用https协议？ - Venkat D.
1
我正在尝试在 GitHub 上进行操作，但没有 git+ssh 选项。 - Steve Walsh
我已经跟踪了TCP流，发现我的账户出现了授权错误。 - Vladimir Nani
12
使用 SourceTree 推送到 BitBucket 时，我每隔几个月就会遇到这个错误。事实证明，我只需要多等五分钟就能自行解决。看起来它似乎已经挂起了，诱惑是直接取消并重试，但也许再坚持一会儿。我知道这个问题已经有答案了，但我的提交可能只有几百千字节而不是原帖作者所说的 40mb。
我也遇到了同样的情况。我在SourceTree中取消了推送，等了大约5分钟，然后再试一次就成功了。 - Neerkoli
@seulberg1 这里还有其他答案，你试过了吗？ - amergin
1
是的，我尝试了不同的git版本，嵌入式-非嵌入式，等待，限制块大小，确保我已经通过身份验证...最终，我能够通过删除最后一个远程提交并将已删除和实际提交一起“重新提交”来解决它。不幸的是，在我的环境中，我无法切换到SSH身份验证。 - seulberg1
1
听起来你有一些同病相怜的伙伴，但我的挂起时间是不确定的。我只梦想5分钟的挂起时间。我已经让它过夜了。一个区别是我的推送是到Github，所以问题可能出在那个服务上。 - cycollins
1
同样的情况在这里！我有6张图片，每张大约20MB，需要等待大约8分钟。 - May W.
显示剩余2条评论
2

在 Git 2.13（2017 年第二季度）中，您将能够将 http.postBuffer 设置为非常大的数字（即在某些平台上大于 ulong）。

请参见 commit 37ee680（2017 年 4 月 11 日），由 David Turner (csusbdt) 提交。
（由 Junio C Hamano -- gitster -- 合并于 commit 4c01f67，2017 年 4 月 24 日）

http.postbuffer：允许使用完整的 ssize_t 值范围

很不幸，在某些��务器不支持分块编码的情况下，为了推送一些大型仓库，http postbuffer有时必须超过两个千兆字节。
在64位系统上，这是可以的：我们只需malloc一个更大的缓冲区即可。 这意味着我们需要使用CURLOPT_POSTFIELDSIZE_LARGE来设置缓冲区大小。
由于Git 2.34（2021年第4季度）不再支持古老版本的cURL库（7.19.4之前），因此结果如下：

查看提交 644de29，提交 013c7e2，提交 1119a15（2021年7月30日），作者为Jeff King (peff)。
查看提交 8dda4cb，提交 5db9d38（2021年7月30日），作者为Ævar Arnfjörð Bjarmason (avar)。
（由Junio C Hamano -- gitster --合并于提交 e48a623，2021年8月24日）

http: 不再支持curl版本低于7.11.1

署名：Jeff King
署名：Ævar Arnfjörð Bjarmason

放弃支持这个古老版本的curl，并简化代码，允许我们摆脱一些“#ifdef”的限制。
由于我们在37ee680（“http.postbuffer：允许使用完整范围的ssize_t值”，2017-04-11，Git v2.13.0-rc1 - merge）中使用了CURLOPT_POSTFIELDSIZE，因此Git将无法使用早于7.11.1的vanilla curl构建。该字段是在curl 7.11.1中引入的。
我们可以通过更多的#ifdefs来解决这些编译问题，但这不值得麻烦。7.11.1版本发布于2004年3月，已经超过17年了。让我们宣布它太老了，并删除任何现有的更早的ifdefs。一个明显的好处是我们将有更少的条件位杂乱的代码。
此补丁删除了所有引用旧版本的#ifdefs（请注意，curl的预处理器宏是十六进制的，因此我们要寻找070b01，而不是071101）。
1
0
在罕见情况下，我使用 SourceTree 推送时会发生这种情况。我发现最好的方法是，如果你卡住了，就直接点击取消，等待一分钟左右，然后再次推送。有时可能需要 3-5 分钟，但大多数情况下都能成功推送。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接