public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "R. Diez" <rdiez-2006@rd10.de>
Cc: git@vger.kernel.org
Subject: Re: git-fetch takes forever on a slow network link. Can parallel mode help?
Date: Tue, 10 Mar 2026 22:50:58 +0000	[thread overview]
Message-ID: <abCgUu3ZFSOIZwKu@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <3ed2d803-5df9-44f4-9427-958d28aa1c46@rd10.de>

[-- Attachment #1: Type: text/plain, Size: 3287 bytes --]

On 2026-03-09 at 21:08:31, R. Diez wrote:
> There is one more thing I am curious about. Git does not document how it uses SSH (or at least I couldn't find it in the standard end-user documentation). Git cannot launch a process on the target host over SSH, unless Git is already installed on the remote system. After all, the local system may have a different architecture (like AMD vs ARM), so you cannot copy a binary across. And I haven't seen the requirement that Git must be installed on the remote host when connecting over SSH. In that case, I would have probably seen somewhere a version compatibility table between client and server.
> 
> So Git must be accessing files over SSH using the standard SSH file transfer operations. I am guessing that the same latency problem will apply here too, because uploads and downloads over SSH will also be sequential. Is my reasoning correct?

Git doesn't use standard SSH file transfer operations.  That would be
much slower and it also works poorly when the remote side doesn't grant
access to a file system, such as with a forge or gitolite.

SSH allows multiple commands to be run over a single connection with
`-oControlMaster`, which can improve performance.  The benefit to
running a single command for each Git operation is that we can do
authentication once at the beginning of each command, whereas if we have
a long-running SSH connection and attempt to do SFTP, we might
interleave requests on different repositories, so each request would
have to perform authentication.  That's not a problem if you're using
Unix permissions to control access, but it scales really poorly when
your Git data is actually spread across many different file servers and
the user is accessing multiple repositories, such as is common on
forges.

Using SSH file transfer operations also would not work well because you
would effectively have to download every pack file and loose object to
be sure you got the data you need, instead of getting a pack with only a
few objects if that's all you need.

However, you can of course mount a remote file system as SFTP with
`sshfs` and use it as a local file system if you actually have a real
file system on the remote side.  That will send multiple requests over
the connection when reading or writing since the `sshfs` does queue
those.

> Or does Git attempt to find out whether there is a Git on the other side? What happens if there isn't then?

Git invokes git-upload-pack on the remote side and talks to it over
standard input and output.  If there isn't one, then the operation
fails.

Here's an example:

----
% GIT_TRACE=1 git ls-remote git@github.com:git/git.git
22:41:36.731673 git.c:502               trace: built-in: git ls-remote git@github.com:git/git.git
22:41:36.731937 run-command.c:673       trace: run_command: unset GIT_PREFIX; GIT_PROTOCOL=version=2 ssh -o SendEnv=GIT_PROTOCOL git@github.com 'git-upload-pack '\''git/git.git'\'''
22:41:36.731952 run-command.c:765       trace: start_command: /usr/bin/ssh -o SendEnv=GIT_PROTOCOL git@github.com 'git-upload-pack '\''git/git.git'\'''
----

I don't have any systems without Git on them, so I can't demonstrate the
failure case.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2026-03-10 22:51 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
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 [this message]
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=abCgUu3ZFSOIZwKu@fruit.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=rdiez-2006@rd10.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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