Re: [PATCH 0/3] Add support for per-remote and per-namespace SSH options
- From
Wesley <wesleys@opperschaap.net>
- Date
- Mar 27, 2026, 16:49 UTC
- Message-ID
- <09c5fe7d-8379-4f68-bf1c-9869e2924cb8@opperschaap.net>
- In-Reply-To
- <xmqqbjg9mex2.fsf@gitster.g>
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. 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.
The alternative is using core.sshCommand to inject the correct keys, but you must apply logic there when you have multiple accounts or forges. Which is what I initially did with a zsh-scripts. Which is why I ported that logic to git itself, I thought it would be beneficial to have an easy way to maintain sshIdentityFile settings.
In addition, for core.sshCommand to work you must use the full openssh command rather than just adding some options to it. Which is an added benefit of the proposed changes.
This change makes key selection possible without too much trouble on the users side with hacks to ssh_config. You can just tell git to use an identity based on the remote. Solve a git identify problem in the git config, fix the problem in the correct domain. We also store email credentials in gitconfigs, why would an ssh identify file be treated different?
> In any case, I do not think these network/transport specific > configuration would hardly belong to "core".
I'm happy to move it elsewhere, as said, I chose core because core.sshCommand. As for the name: "ssh" or "transport", I'm not certain what is the best option is.
Cheers, Wesley
-- Wesley Why not both?