Re: git push --mirror hung indefinitely

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Mar 28, 2025, 19:39 UTC
Message-ID: <Z-b66vVzQRFFHFK_@tapette.crustytoothpaste.net>
In-Reply-To: <SA1PR19MB7013490588962D983094128DC0A02@SA1PR19MB7013.namprd19.prod.outlook.com>

On 2025-03-28 at 10:37:43, Akash S wrote:

Show 12 quoted lines

> Hi,
> 
> We are attempting to push a bare repository on our local disk to Azure DevOps using the command "git push -mirror <URL>".
> 
> Git version being used: 2.48.1 and no global git configurations exist in the machine.
> 
> Issue: command progresses for 5-10 mins and then the git processes get hung after we see the output "Storing index (done)" and remains hung indefinitely.
> 
> Steps to reproduce:
> i) Bare clone open source repo (elasticsearch or node) to local disk.
> ii) Run "git lfs push -mirror" to any repository in an Azure DevOps organization using PAT authentication.
> iii) Issue happens intermittently, so alternating the push operation between the local elasticsearch and node repo to the same remote repository should help recreate the issue.

Does this happen if you push it to a different server? From what it looks like here, it might be the server not sending anything back in time.

Also, do you have anything intercepting TLS, like a non-default antivirus or firewall or any sort of proxy? Sometimes such tools buffer the output of the request, which can break things[0]. If you do, you should either uninstall the software completely and reboot (since disabling it is often not sufficient) or change networks if there's a proxy or TLS MITM device on the network and see if it's fixed.

> Workaround steps taken by us to not face this issue:
> 
> i) Since our repository is quite large (1.5 GB), we set http.postBuffer to 50 MB, it did not help in resolving the issue.

`http.postBuffer` simply sets the value below which the entire body is sent with a content-length instead of using chunked transfer encoding. As outlined in the Git FAQ[1], this option doesn't need to be set unless you have a server or proxy which doesn't handle HTTP/1.1 properly, and in general those are rare (because a lot of stuff would be broken). I'm sure Azure DevOps is not broken in that way.

Since it almost certainly isn't needed, I'd remove it, since it just tends to waste a lot of memory if you don't need it.

Show 7 quoted lines

> Thread 2 (Thread 0x7fa246a18700 (LWP 1043384)):
> #0  0x00007fa24ce568e4 in read () from /lib64/libpthread.so.0
> #1  0x000000000066a07e in xread (fd=fd@entry=0, buf=buf@entry=0x7fa246a07d7c, len=len@entry=4) at wrapper.c:234
> #2  0x000000000066a1eb in read_in_full (fd=0, buf=buf@entry=0x7fa246a07d7c, count=count@entry=4) at wrapper.c:292
> #3  0x00000000005c4d32 in get_packet_data (fd=fd@entry=0, src_buf=src_buf@entry=0x0, src_size=src_size@entry=0x0, dst=dst@entry=0x7fa246a07d7c, size=size@entry=4, options=options@entry=1) at pkt-line.c:354
> #4  0x00000000005c5827 in packet_read_with_status (fd=fd@entry=0, src_buffer=src_buffer@entry=0x0, src_len=src_len@entry=0x0, buffer=buffer@entry=0x7fa246a07e20 "\001\060\060\061aok refs/tags/v0.10.45\n", size=size@entry=65520, pktlen=pktlen@entry=0x7fa246a07df8, options=1) at pkt-line.c:422
> #5  0x00000000005c5fa9 in recv_sideband (me=me@entry=0x6e35ea "send-pack", in_stream=0, out=out@entry=5) at pkt-line.c:586

This looks like it's waiting to read a pkt-line header, which should be sent periodically by the server, so my guess is that this is particular to the server that you're using, or, as I mentioned above, that you have something in the middle that's intercepting the data.

[0] https://git-scm.com/docs/gitfaq#proxy [1] https://git-scm.com/docs/gitfaq#http-postbuffer

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA