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

Asked 28/5, 2012 at 20:44 Answered 22/12, 2022 at 16:15

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://[email protected]/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?

Neisse answered 28/5, 2012 at 20:44 Comment(3)

I have the same problem, same error message, sourcetree & github end up freezing and crashing. I tried the command suggested below and now it says something similar: "POST git-receive-pack ({Some 9 digit long number})" – Centrality 31/5, 2015 at 14:37

I had to update my Git version https://mcmap.net/q/244072/-git-push-hangs-on-post-git-receive-pack – Plaided 26/6, 2015 at 3:26

Always worth checking the status page - I was unable to push a new repository just now and found BitBucket SSH was down… – Darsie 17/7, 2020 at 17:0

161

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

Lusty answered 30/1, 2013 at 0:10 Comment(8)

still hangs on windows in git v1.9.5.msysgit.1 – Mixer 12/6, 2015 at 8:20

Setting postBuffer didn't help me, either, but updating to the pre-release of Git for Windows did (per https://mcmap.net/q/244072/-git-push-hangs-on-post-git-receive-pack) – Gumption 29/6, 2015 at 15:26

@Gumption this should posted as a solution, not a comment – Gathering 31/8, 2015 at 14:26

This error was because ngix was configured to reject large files, so instead of add a more large buffer, you should put it on a range that your server (in my case nix default config) accepts. git config http.postBuffer 5242should being chunks of about 5k. – Devastate 3/9, 2015 at 0:27

In my case I had to reduce the post buffer size to 5000 as noted by @Devastate – Coffeecolored 9/11, 2015 at 15:53

By the way, the final "good" way should be to add the remote public keys of your user to gitlab so it is enabled to use SSH instead of HTTPS, so it can handle now large files (except if the server rejects them as policy like github I guess will be do in future/now). – Devastate 10/11, 2015 at 16:35

BTW on a Mac I had to edit ~/.gitconfig manually, then just added in section [http] the line: postBuffer = 524288000 – Discophile 10/2, 2016 at 13:43

I've solved by reducing the size as tyoc213 said. Working with github... – Olson 27/5, 2023 at 14:17

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

Univocal answered 28/5, 2012 at 21:9 Comment(3)

Worked for me also. Any ideas why it won't work with the https protocol? – Clodhopping 16/9, 2012 at 15:49

I'm trying to do this for github, but there is no git+ssh option. – Thesis 7/11, 2012 at 14:40

I have followed TCP stream and it was Authorization error for my account. – Firetrap 8/7, 2015 at 9:21

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.

Pouter answered 13/2, 2015 at 9:8 Comment(7)

Same case for me. I cancelled the push in SourceTree and waited for like 5 mins, tried again and it worked. – Portsmouth 7/12, 2015 at 13:23

same story here – Whimper 2/12, 2016 at 10:11

I waited for about an hour (28mb commit) - nothing, absolutely nothing happened. – Treadmill 31/1, 2019 at 20:48

@Treadmill There are other answers here, have you tried them? – Pouter 1/2, 2019 at 0:22

Yes, I tried different git versions, embedded - non embedded, waiting, limiting the chunk size, made sure I was authenticated.... In the end, I was able to solve it by deleting the last remote commit and "re-commit" the removed and the actual commit in one big chunk. Unfortunately, in my environment, I cannot switch to SSH authentication. – Treadmill 1/2, 2019 at 0:46

Sounds like you've got some partners in misery, but my hang is indefinite. I dream of only 5-minute hangs. I've left it overnight. One difference is that my push is to Github, so the problem may lie with that service. – Septet 17/11, 2022 at 5:42

same here! I have 6 pictures, all around 20mb, wait about 8mins. – Butterworth 21/12, 2022 at 18:30

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).

Hays answered 24/4, 2017 at 21:22 Comment(0)

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

how to use git extension with bitbucket repository?

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

Dunham answered 24/11, 2013 at 15:35 Comment(0)

On rare occasions, this happens when I use SourceTree to push. I've found that it's best to just hit cancel if you've been stuck, wait a minute or so, and then push again. Sometimes it could take 3-5 minutes, but most of the time it successfully pushes.

Stolid answered 22/12, 2022 at 16:15 Comment(0)

`http.postbuffer`: allow full range of `ssize_t` values

`http`: drop support for curl < 7.11.1

Recommended topics

Hot tags

http.postbuffer: allow full range of ssize_t values

http: drop support for curl < 7.11.1

Recommended topics

Hot tags

`http.postbuffer`: allow full range of `ssize_t` values

`http`: drop support for curl < 7.11.1