From: Wesley <wesleys@opperschaap.net>
To: Johannes Sixt <j6t@kdbg.org>
Cc: Git maillinglist <git@vger.kernel.org>
Subject: Re: [PATCH 0/3] Add support for per-remote and per-namespace SSH options
Date: Fri, 27 Mar 2026 11:04:01 -0400 [thread overview]
Message-ID: <abe2616d-4dbc-4d84-9fa9-a6d24cd65927@opperschaap.net> (raw)
In-Reply-To: <7d3731c5-d766-47f5-af60-813b379cbeef@kdbg.org>
On 3/27/26 03:51, Johannes Sixt wrote:
> 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
> For this reason, I see little incentive to add complexity to Git that
> achieves the same.
It's a hacky solution where you change the ssh configuration
permanently. It breaks copy/paste(s) etc for every forge.
In addition, this is where my need came from: It breaks myrepo's
configuration(s) for people if they have to override the hostname in
each myrepos config. You cannot simply override the hostname in these
situtations because of a local ssh config change.
Cheers,
Wesley
--
Wesley
Why not both?
next prev parent reply other threads:[~2026-03-27 15:04 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 [this message]
2026-03-27 16:10 ` Junio C Hamano
2026-03-27 16:49 ` Wesley
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=abe2616d-4dbc-4d84-9fa9-a6d24cd65927@opperschaap.net \
--to=wesleys@opperschaap.net \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.