Subject: Re: [PATCH 0/3] Add support for per-remote and per-namespace SSH options

From: Ben Knoble <[email-masked]>
Date: Sun, 29 Mar 2026 10:33:58 -0400

> Le 28 mars 2026 à 11:02, Wesley <[email-masked]> a écrit :
> 
> On 3/28/26 03:46, Johannes Sixt wrote:
> 
>>> And not portable across
>>> teams with configurations committed to git. Myrepos is a good example of
>>> this. My former employer had this and I know the Perl metacpan project
>>> also uses mysrepos. Changing every URL dynamically in committed configs
>>> isn't really a nice ask.
>> I cannot comment on this, because I do not know these tools.
>> There are ways to achieve a considerable amount of customization of SSH
>> connections with existing tools. If you need additional features, you
>> should sell your change with a more specific justification, including
>> examples that show reviewers who do not know the tools you are using
>> what is needed, but missing.
> 
> The ways to do it all involve configuring ssh to configure git, instead of configuring git to configure git. The remote is already configured in git, having your sshIndentityFile and possible other options close to that configuration is beneficial to users. The escape-hatch of core.sshCommand doesn't need to be utilized for a simple "Use this indentityFile on this remote".

Hm. But if you’re connecting to a host (Git or otherwise) via SSH, isn’t the natural place to configure that the SSH client?

I use custom host config to control identify files so that each host I connect to gets a unique identity; some are Git hosts, some are other things.

I don’t yet deal with different connections to the same host, so the only Git configuration I make is to rewrite some HTTPS remote URLs to SSH connection strings. 

> The only way to configure git without touching ssh

I think I, at least, claim that this is Git working with SSH, so it is natural that both sides may require tuning. 

> There is no need to configure both ssh and possible git with rewrite rules with this patch. Which to me is a cleaner solution. One knob in git for git.

Hence let each do what they do best :) each knob where it belongs.

Just my 2¢. Cheers!