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.
