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

From: Wesley <wesleys@opperschaap.net>
Date: Mar 28, 2026, 14:59 UTC
Message-ID: <3d8c9b3f-66d0-460d-bd61-a879a6bbfc56@opperschaap.net>
In-Reply-To: <becf040c-b425-4fd1-affa-b6368c812b42@kdbg.org>

On 3/28/26 03:46, Johannes Sixt wrote:

Show 17 quoted lines

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

Show 13 quoted lines

>> 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?