From: Wesley <wesleys@opperschaap•net>
To: Junio C Hamano <gitster@pobox•com>
Cc: git@vger•kernel.org, Johannes Sixt <j6t@kdbg•org>
Subject: Re: [PATCH 0/3] Add support for per-remote and per-namespace SSH options
Date: Fri, 27 Mar 2026 12:49:35 -0400 [thread overview]
Message-ID: <09c5fe7d-8379-4f68-bf1c-9869e2924cb8@opperschaap.net> (raw)
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?
next prev parent reply other threads:[~2026-03-27 16:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 23:37 [PATCH 0/3] Add support for per-remote and per-namespace SSH options Wesley Schwengle
2026-03-26 23:37 ` [PATCH 1/3] connect: Rename name to command in connect_git() Wesley Schwengle
2026-03-27 21:33 ` Jeff King
2026-03-28 0:58 ` Wesley
2026-03-28 1:44 ` Jeff King
2026-03-28 2:01 ` Wesley
2026-03-26 23:37 ` [PATCH 2/3] connect: Add transport->remote->name to git_connect() Wesley Schwengle
2026-03-27 21:39 ` Jeff King
2026-03-26 23:37 ` [PATCH 3/3] connect: Add support for per-remote and per-namespace SSH options Wesley Schwengle
2026-03-27 21:45 ` Jeff King
2026-03-28 0:43 ` Wesley
2026-03-28 2:03 ` Jeff King
2026-03-28 2:25 ` Wesley
2026-03-27 7:51 ` [PATCH 0/3] " Johannes Sixt
2026-03-27 15:04 ` Wesley
2026-03-27 16:10 ` Junio C Hamano
2026-03-27 16:49 ` Wesley [this message]
2026-03-27 22:06 ` brian m. carlson
2026-03-28 1:02 ` Wesley
2026-03-28 7:46 ` Johannes Sixt
2026-03-28 14:59 ` Wesley
2026-03-29 14:33 ` Ben Knoble
2026-03-27 21:51 ` brian m. carlson
2026-03-27 22:25 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=09c5fe7d-8379-4f68-bf1c-9869e2924cb8@opperschaap.net \
--to=wesleys@opperschaap$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=j6t@kdbg$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox