git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
RDR. 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
Previous: brian m. carlsonNext: brian m. carlson
Message 3 of 9 in “git-fetch takes forever on a slow network link. Can parallel mode help?”
  1. R. DiezMar 6, 2026
  2. brian m. carlsonMar 6, 2026
  3. R. DiezMar 7, 2026
  4. brian m. carlsonMar 8, 2026
  5. R. DiezMar 8, 2026
  6. brian m. carlsonMar 8, 2026
  7. R. DiezMar 9, 2026
  8. brian m. carlsonMar 10, 2026
  9. R. DiezMar 11, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.