Re: git-fetch takes forever on a slow network link. Can parallel mode help?
- From
- R. Diez <rdiez-2006@rd10.de>
- Date
- Mar 7, 2026, 21:28 UTC
- Message-ID
- <1d6a8eec-20b3-4d6e-83f1-d18b7a3c0145@rd10.de>
- In-Reply-To
- <aas--JZ-CCWN-o7O@fruit.crustytoothpaste.net>
Hallo Brian:
First of all, thanks for your quick feedback.
> Since this is presumably a bare repository,
Yes, the remote repository is bare.
> [...] > This performance could be improved with `git pack-refs`
After looking around, it turns out that the documentation of "git gc" says that "packing refs" is one of the things it already does.
I'll check when it was the last time I did a "git gc" on the remote bare repository, when I'm there again.
> or by converting to the reftable backend, which will open fewer files.
The documentation states: "reftable for the reftable format. This format is experimental and its internals are subject to change.". I am not ready to risk it yet on my precious Git repository. 8-)
> [...] > You can also see how long various operations take by using > `GIT_TRACE2=1`, which will give some detailed timing information that > will help you see what the expensive parts are.
That didn't help much. Most of the time (23.7 from 24 seconds) is spent in a single child process: child_start[0] 'git-upload-pack '\''/home/rdiez/MountPoints/blah/blah'\'''
The log talks about "upload pack", but I gather this is actually a download operation. It wouldn't be the first confusing item in Git. Or have I got it wrong?
I added "export GIT_TRACE_PACKET=true", and then I got a more useful breakdown:
This takes around 13 seconds:
pkt-line.c:85 packet: upload-pack< 0000
I don't know what 0000 means. All other similar "upload-pack" lines have a hash there.
About 2 seconds are spent here:
pkt-line.c:85 packet: upload-pack> [some hash] HEAD symref-target:refs/heads/master pkt-line.c:85 packet: upload-pack> [some hash] refs/heads/master
7 seconds are spent with "upload-pack" and "fetch" operations, mainly for single "refs/tags". I'll check whether that improves after the next "git gc" on the server.
>> 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. > > Parallel mode does not help with a single remote. All the data for a single remote comes in one job.
Is this due to a simple implementation in Git? Could Git download such "refs/tags" files in parallel?
Best regards, rdiez