From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 27 Mar 2026 16:10:33 GMT
Subject: Re: [PATCH 0/3] Add support for per-remote and per-namespace SSH options
Message-ID: <xmqqbjg9mex2.fsf@gitster.g>
In-Reply-To: <7d3731c5-d766-47f5-af60-813b379cbeef@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

> Am 27.03.26 um 00:37 schrieb Wesley Schwengle:
>> * `remote.*.sshIdentityFile' and `remote.*.sshOpts'
>> 
>> Configuration set on owner/path style. This is to support `includeIf`
>> configuration management. For example, a git-forge that host both
>> employer/client repo's. Eg, `git@gitlab.com/waterkip/git.git' and
>> `git@gitlab.com/corp/git.git' would have something configured as:
>> 
>> * `core.sshIdentityFile.*', eg
>> 
>>     [core "sshIdentityFile"]
>>       waterkip = ~/.ssh/id_ed25519_me
>>       corp     = ~/.ssh/id_ed25519_corporate
>
> This can be solved without a changing Git today. You configure the two
> remotes with different fake host names:
>
> [remote "waterkip"]
>   url = git@waterkip.gitlab/waterkip/git.git
> [remote "corp"]
>   url = git@corp.gitlab/corp/git.git

> And set up the real host name and identity file in ~/.ssh/config:
>
> Host waterkip.gitlab
>   IdentityFile ~/.ssh/id_ed25519_me
>   HostName gitlab.com
>
> Host corp.gitlab
>   IdentityFile ~/.ssh/id_ed25519_corporate
>   HostName gitlab.com
>
>
> For this reason, I see little incentive to add complexity to Git that
> achieves the same.

Very well said.

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?

In any case, I do not think these network/transport specific
configuration would hardly belong to "core".