Git push hang/freeze in Windows - with solution

[Michael Haben]

For the last few days I've been seeing a problem on my Windows 10 PC where "git push origin main" (pushing to a BitBucket-hosted repo) in Git-Bash would hang:

$ git push
Enumerating objects: 134, done.
Counting objects: 100% (116/116), done.
Delta compression using up to 8 threads
Compressing objects: 100% (48/48), done.
Writing objects: 100% (101/101), 111.82 KiB | 27.95 MiB/s, done.
Total 101 (delta 65), reused 82 (delta 52), pack-reused 0

Adding verbosity options "GIT_TRACE=1 GIT_CURL_VERBOSE=1 git push" showed more:

...
Enumerating objects: 134, done.
Counting objects: 100% (116/116), done.
Delta compression using up to 8 threads
Compressing objects: 100% (48/48), done.
Writing objects: 100% (101/101), 111.82 KiB | 37.27 MiB/s, done.
Total 101 (delta 65), reused 82 (delta 52), pack-reused 0
14:59:37.459035 http.c:843 == Info: Found bundle for host: 0x20854357e30 [can multiplex]
14:59:37.459035 http.c:843 == Info: Re-using existing connection #0 with host bitbucket.org
14:59:37.459035 http.c:843 == Info: Server auth using Basic with user 'mike_h3'
14:59:37.459035 http.c:843 == Info: h2 [:method: POST]
14:59:37.459035 http.c:843 == Info: h2 [:scheme: https]
14:59:37.459035 http.c:843 == Info: h2 [:authority: bitbucket.org]
14:59:37.459035 http.c:843 == Info: h2 [:path: /h3-structuraltech/pc_test_app.git/git-receive-pack]
14:59:37.459035 http.c:843 == Info: h2 [authorization: Basic <redacted>]
14:59:37.459035 http.c:843 == Info: h2 [user-agent: git/2.41.0.windows.3]
14:59:37.459035 http.c:843 == Info: h2 [accept-encoding: deflate, gzip, br, zstd]
14:59:37.459035 http.c:843 == Info: h2 [content-type: application/x-git-receive-pack-request]
14:59:37.459035 http.c:843 == Info: h2 [accept: application/x-git-receive-pack-result]
14:59:37.459035 http.c:843 == Info: h2 [content-length: 114684]
14:59:37.459035 http.c:843 == Info: Using Stream ID: 7 (easy handle 0x20854366320)
14:59:37.459035 http.c:790 => Send header, 0000000532 bytes (0x00000214)
14:59:37.459035 http.c:802 => Send header: POST /h3-structuraltech/pc_test_app.git/git-receive-pack HTTP/2
14:59:37.459035 http.c:802 => Send header: Host: bitbucket.org
14:59:37.459035 http.c:802 => Send header: Authorization: Basic <redacted>
14:59:37.459035 http.c:802 => Send header: User-Agent: git/2.41.0.windows.3
14:59:37.459035 http.c:802 => Send header: Accept-Encoding: deflate, gzip, br, zstd
14:59:37.459035 http.c:802 => Send header: Content-Type: application/x-git-receive-pack-request
14:59:37.459035 http.c:802 => Send header: Accept: application/x-git-receive-pack-result
14:59:37.459035 http.c:802 => Send header: Content-Length: 114684
14:59:37.459035 http.c:802 => Send header:
14:59:37.519034 http.c:843 == Info: We are completely uploaded and fine

I tried a "git bundle create", then cloning from that Git-bundle, adding the same remote repo to the new cloned repo and pushing, but saw exactly the same behaviour.

TLDR is... files that were initially included in a commit, but later excluded via the .gitignore file were still present, and deleting them fixed the issue.

Shortly before the problem showed itself, I'd added an entire new Visual Studio project to my repo: "git add MyNewProj/", which had of course added not just the project file and source-code files, but build-artefact files in folders MyNewProj/bin and MyNewProj/obj.  I'd then edited my .gitignore file to make Git ignore these two sub-folders, but hadn't deleted them (or "git rm"'d them) from the filesystem.  I have TortoiseGit installed, and both of these folders were still being shown by Windows Explorer with TortoiseGit's green overlay-icon.  I'm pretty sure these two subfolders + contents had also been included by the "git bundle create" and were then present when I "git clone"'d a new copy of the repo from that bundle.  I Shift-Deleted MyNewProj/bin and MyNewProj/obj in Windows Explorer, then went back to Git-Bash and did "git push" - and it worked as normal.

Versions: git version 2.41.0.windows.3, TortoiseGit 2.14.0.0 (Hotfix 2.14.0.1).

I'm not sure whether this is a problem inherent in Git, or specific to BitBucket.  I'll try to find time to reproduce the issue in a "demo" repo that doesn't contain customer code, but don't wait up for that.

[Tomislav Tobijas]

Hi @Michael Haben ,

Just to check - is this in any way related to Sourcetree or just with Bitbucket? I'm asking as it landed in the Sourcetree Q&A section.

From what I've found, it appears to be a known compatibility issue between that specific Git version and Bitbucket Cloud's HTTP/2 implementation 👀

A couple of recommendations (relatively AI-generated) I've gathered:

1. Update Git for Windows (Primary Fix)

The most effective resolution is to upgrade your Git client to the latest stable version (anything newer than 2.41.0).

• Download the latest installer from the official Git page.

• After installing, verify the version with git --version to ensure it is no longer 2.41.0.

2. Increase the HTTP Post Buffer

If you cannot upgrade immediately, increasing the http.postBuffer allows Git to handle larger data transfers before the connection times out or hangs.

• Run the following command in Git-Bash:
  git config --global http.postBuffer 524288000 (sets it to 500MB).

3. Force HTTP/1.1

Since the hang is specific to HTTP/2 multiplexing, you can force Git to use the older HTTP/1.1 protocol for your pushes.

• Use this command for a single push:
  git -c http.version="HTTP/1.1" push.

• Or set it globally:
  git config --global http.version HTTP/1.1.

Or you could try switching to SSH as it can often bypass these protocol-level hangs. 🤔

Cheers,
Tobi

[Michael Haben]

Thanks Tobi - so just my bad luck to be using the one version of Git that has the problem!  Updating now...