From: Jeff King <peff@peff.net>
Date: Fri, 27 Mar 2026 21:39:54 GMT
Subject: Re: [PATCH 2/3] connect: Add transport->remote->name to git_connect()
Message-ID: <20260327213954.GB598533@coredump.intra.peff.net>
In-Reply-To: <20260326233739.2911354-3-wesleys@opperschaap.net>

On Thu, Mar 26, 2026 at 07:37:37PM -0400, Wesley Schwengle wrote:

> To support `remote.$name.sshIdentityFile', and `remote.$name.sshOpts' for
> connecting to various remotes I need to pass around the remote down to
> git_connect. This commit introduces the `remote_name' and sprinkles all
> call sites to pass `NULL'. This is a non-breaking forward change

My gut feeling is here is that this is going to be the wrong level for
reading config, because it's too low and too coarse. If we ever want to
have a command-line option for overriding config, like "git fetch
--ssh-identity-file=foo", then how can the higher level git-fetch code
pass down that single item?

I.e., I think the ideal form of this would be that we pass around an
ssh_options_context struct, high-level commands fill in that struct
based on command-line options or config (including remote-specific
ones), and then we act on it at the lowest level when spawning ssh.


All that said, my first thought here is that most of what this series
does is already possible with ssh config. It looks like that has already
been suggested elsewhere in the thread, so I'll go read that before
commenting further.

-Peff