From: "R. Diez" <rdiez-2006@rd10•de>
To: "brian m. carlson" <sandals@crustytoothpaste•net>
Cc: git@vger•kernel.org
Subject: Re: git-fetch takes forever on a slow network link. Can parallel mode help?
Date: Sat, 7 Mar 2026 22:28:10 +0100 [thread overview]
Message-ID: <1d6a8eec-20b3-4d6e-83f1-d18b7a3c0145@rd10.de> (raw)
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
next prev parent reply other threads:[~2026-03-07 21:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-06 20:13 git-fetch takes forever on a slow network link. Can parallel mode help? R. Diez
2026-03-06 20:54 ` brian m. carlson
2026-03-07 21:28 ` R. Diez [this message]
2026-03-08 1:44 ` brian m. carlson
2026-03-08 21:08 ` R. Diez
2026-03-08 22:52 ` brian m. carlson
2026-03-09 21:08 ` R. Diez
2026-03-10 22:50 ` brian m. carlson
2026-03-11 18:05 ` R. Diez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1d6a8eec-20b3-4d6e-83f1-d18b7a3c0145@rd10.de \
--to=rdiez-2006@rd10$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=sandals@crustytoothpaste$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox