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

From: Wesley <[email-masked]>
Date: Sat, 28 Mar 2026 10:59:47 -0400

On 3/28/26 03:46, Johannes Sixt wrote:
> Am 27.03.26 um 17:49 schrieb Wesley:
>> On 3/27/26 12:10, Junio C Hamano wrote:
>>> I somehow thought that this practice is so widespread that it was
>>> one of the few first things any new people learn to do, but perhaps
>>> we do not have a good documentation coverage?
>>
>> As said before it is weird thing to configure a global ssh configuration
>> just for git transport. It doesn't make much sense.
>>
>> The problem with ssh_config usage is that you need to change your ssh
>> config, which is machine global, not just git.
> 
> Are thinking about the SSH configuration in /etc/ssh? You do not have to
> change that. There is also a .ssh/config in the user's home directory.
> That configuration isn't machine global, it's obviously per user. And
> the way to make the configuration work only for Git is precisely to use
> fake host names that are only used in remote URLs of Git repositories.

I refered to that as the .ssh/config unit. But /etc/ssh/ssh_config is a 
more global setting indeed.

>> 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".

The only way to configure git without touching ssh is to fiddle with the 
core.sshCommand, which I did in my own zsh script. This script also 
utilized the git config, I used my own namespace for this, which in this 
patch became "core". The whole idea was: git owns git operations, thus 
the config should live in git.

The need for me arose precisely because upstream encoded git repos on a 
forge where my personal projects also resided and forced me to create a 
second account. Having to change ssh config was to me the wrong knob to 
turn. I fixed it years ago, and while refactoring it I thought the 
pattern would be helpful for every git user resulting in the above patch.

I think this is helpful for freelancers who have multiple clients and 
don't feel the need to add a specific host in their .ssh/config for each 
client. They can includeIf it, setting repos with a particular "owner" 
to a specific identity file or they can set it on remote level basis if 
the need is there. That is why the cascading configuration was added.

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.

Cheers,
Wesley

-- 
Wesley

Why not both?