Subject: git-fetch takes forever on a slow network link. Can parallel mode help?

From: "R. Diez" <[email-masked]>
Date: Fri, 6 Mar 2026 21:13:58 +0100

Hi all:

I have an SMB/CIFS connection to a file server over a slow link of about 1 Mbps download, and a faster upload of about 10 Mbps.

My smallish Git repository has its single origin on that file server. Unfortunately, I cannot set up any sort of Git server on the remote host.

git fetch takes a long time. If the repository is up to date, it takes about 25 seconds to realise that there is nothing to do.

If there are changes to download, it can take half an hour, even if the new commit history is rather small.

The network link is slow, but not that slow. I wonder what may be causing the long delays.

The first question is: how come it takes so long to determine that nothing has changed? Does git-fetch need to download a biggish file every time?

Perhaps latency is more of an issue than bandwidth. I saw that git-fetch can work in parallel with --jobs=n . Doing parallel requests may help against round trip latency.

However, the git-fetch documentation does not clearly state whether the parallel mode only helps if you have multiple remotes and/or multiple submodules. In my case, I just have a single repository with a single origin and no submodules.

Adding --jobs=10 does not help in the 25-second case with no new commits to download.

Does anybody have any ideas about how to improve performance in this scenario?

Thanks in advance,
   rdiez