git fetch with refspec not using proxy?

[grandinj]

So I am behind a proxy. And I tell git about it about by doing

export https_proxy=http://proxy.com:3128

and then

git fetch https://gerrit.collaboraoffice.com/online

works fine. But.....

git fetch https://gerrit.collaboraoffice.com/online refs/changes/81/15581/14

does not. It just gets stuck, doing nothing.

Any ideas?

[danilablagorodniy37]

Both commands do go through the proxy. I ran them from a Git for Windows 2.48.1 clone of that repository with https_proxy pointing at a local proxy that logs every request: with and without the refspec, GIT_CURL_VERBOSE=1 prints Establish HTTP proxy tunnel to gerrit.collaboraoffice.com:443 and the proxy logs a CONNECT gerrit.collaboraoffice.com:443 for each run. So the refspec does not make git bypass https_proxy.

What differs is what happens inside the tunnel:

• git fetch https://gerrit.collaboraoffice.com/online only fetches HEAD. In an up-to-date clone that is the ref listing and no pack data at all (0.7 s here, HEAD -> FETCH_HEAD).
• git fetch https://gerrit.collaboraoffice.com/online refs/changes/81/15581/14 is the first request that makes Gerrit build and send a pack. After the client sends its done, the server is silent while it assembles the pack, and only then do bytes start flowing again. From here, GIT_TRACE_PACKET=1 timestamps show about 10 seconds of silence for the smallest possible pack for that change (6 MB, --depth 1 into a clone that already had HEAD); a request that made the server enumerate the whole history was still silent after 9 minutes. Nothing crosses the CONNECT tunnel during that phase, and git itself has no read timeout, so if the proxy drops an idle tunnel, git waits forever with no output, which matches "stuck, doing nothing".

To see which of the two it is, run the fetch with tracing:

GIT_CURL_VERBOSE=1 GIT_TRACE_PACKET=1 git fetch https://gerrit.collaboraoffice.com/online refs/changes/81/15581/14

If the output ends with fetch> done and the headers of the POST /online/git-upload-pack request, the request reached the server and you are waiting for the pack (or for a tunnel the proxy has already cut). An error from the proxy would show up right there instead, for example Received HTTP code ... from proxy after CONNECT.

To make the wait fail instead of hang, you can give the transfer a low-speed timeout for that one command. After 60 s without data it aborts with Operation too slow. Less than 1000 bytes/sec transferred the last 60 seconds (keep the time long enough for the server's pack-building pause):

git -c http.lowSpeedLimit=1000 -c http.lowSpeedTime=60 fetch https://gerrit.collaboraoffice.com/online refs/changes/81/15581/14

If it turns out to be the proxy's idle timeout, the options are asking the proxy admin about the timeout for CONNECT tunnels, or fetching that change over Gerrit's SSH port (ssh://<user>@gerrit.collaboraoffice.com:29418/online) if your network lets SSH out, which does not involve the HTTP proxy at all.

[grandinj]

Thank you! That was useful.

It turns out that shallow-clone and gerrit do not play nicely together.

The shallow clone works fine, but then any attempt to cherry-pick from that gerrit server makes the server spend forever computing results.