Hanging at "POST git-receive-pack (chunked)"

GitVersion ControlBitbucket

Git Problem Overview


I will be honest, I know very little about the internals of git.

I have staged and commit a 40mb directory, but when I come to push...

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

It's been like this for 20 minutes. I am assuming it's hanging but...is there anything I can do to find out why?

Git Solutions


Solution 1 - Git

This is a bug in Git; when using HTTPS it will use chunked encoding for uploads above a certain size. Those do not work.

A trivial fix is to tell git to not chunk until some ridiculously large size value, such as:

git config http.postBuffer 524288000

Solution 2 - Git

Probably your credentials. Use the git+ssh protocol instead of https.

Solution 3 - Git

Using SourceTree to push to BitBucket I get this error once every few months. It turns out that I just have to wait an extra five minutes and it sorts itself out. It looks like it has hanged and the temptation is to just cancel and try again but maybe hang in there a bit longer. I know that this is answered already but my commits amounted to maybe a couple of hundred kb rather than the 40mb the original poster is talking about.

Solution 4 - Git

With Git 2.13 (Q2 2017), you will be able to set http.postBuffer to a really large number (i.e, larger than ulong on some platforms).

See commit 37ee680 (11 Apr 2017) by David Turner (csusbdt).
(Merged by Junio C Hamano -- gitster -- in commit 4c01f67, 24 Apr 2017)

> ## http.postbuffer: allow full range of ssize_t values

> Unfortunately, in order to push some large repos where a server does not support chunked encoding, the http postbuffer must sometimes exceed two gigabytes.
On a 64-bit system, this is OK: we just malloc a larger buffer. > > This means that we need to use CURLOPT_POSTFIELDSIZE_LARGE to set the buffer size.


As a result, with Git 2.34 (Q4 2021) which drops support for ancient versions of cURL library (pre 7.19.4):

See commit 644de29, commit 013c7e2, commit 1119a15 (30 Jul 2021) by Jeff King (peff).
See commit 8dda4cb, commit 5db9d38 (30 Jul 2021) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit e48a623, 24 Aug 2021)

> ## http: drop support for curl < 7.11.1
> Signed-off-by: Jeff King
> Signed-off-by: Ævar Arnfjörð Bjarmason

> Drop support for this ancient version of curl and simplify the code by allowing us get rid of some "#ifdef"'s.
> > Git will not build with vanilla curl older than 7.11.1 due our use of CURLOPT_POSTFIELDSIZE in 37ee680 ("http.postbuffer: allow full range of ssize_t values", 2017-04-11, Git v2.13.0-rc1 -- merge).
> This field was introduced in curl 7.11.1.
> > We could solve these compilation problems with more #ifdefs, but it's not worth the trouble.
> Version 7.11.1 came out in March of 2004, over 17 years ago.
> Let's declare that too old and drop any existing ifdefs that go further back.
> One obvious benefit is that we'll have fewer conditional bits cluttering the code.
> > This patch drops all #ifdefs that reference older versions (note that curl's preprocessor macros are in hex, so we're looking for 070b01, not 071101).

Solution 5 - Git

If you found this site because of BitBucket failing with that error message, then check out the answers to this one:

Particularly the comment by Nicholas Pickering and Simon Tewsi about exactly what part of the key needs to be pasted into the BitBucket dialog.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionAntony WoodsView Question on Stackoverflow
Solution 1 - GitScott HooperView Answer on Stackoverflow
Solution 2 - GitAdam DymitrukView Answer on Stackoverflow
Solution 3 - GitamerginView Answer on Stackoverflow
Solution 4 - GitVonCView Answer on Stackoverflow
Solution 5 - GitRichard Le MesurierView Answer on Stackoverflow