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

From: Wesley <wesleys@opperschaap.net>
Date: Mar 28, 2026, 00:43 UTC
Message-ID: <a4a03bae-b987-4b21-a7fd-fbdb9d832430@opperschaap.net>
In-Reply-To: <20260327214559.GA599365@coredump.intra.peff.net>

On 3/27/26 17:45, Jeff King wrote:

Show 23 quoted lines

> On Thu, Mar 26, 2026 at 07:37:38PM -0400, Wesley Schwengle wrote:
> 
>> The following configuration is supported, in order of precedence:
>>
>>    1. `remote.<name>.sshIdentityFile' and `remote.<name>.sshOpts'
>>
>>    2. `core.sshIdentityFile.<owner>' and `core.sshOpts.<owner>'
>>
>>       Where <owner> is derived from the repository path. Nested groups
>>       aren't supported: git@host:owner/repo.git becomes "owner",
>>       git@host:owner/group/repo.git also becomes "owner".
> 
> We already have some conditional config mechanisms, and I don't think
> it's a good idea to add one that only works for certain keys. If I
> understand correctly, this <owner> feature can already be accomplished
> with:
> 
>    [includeIf "hasconfig:remote.*.url:**/owner/**"]
>    path = all-your-options-for-that-owner
> 
> It's a little more verbose (and you have to use a separate file), but it
> also allows other conditions, like "gitdir:" for selecting based on how
> you lay out your repos locally.

This doesn't work as you would think it does. The includeIf on hasconfig with the remote URL is used if it finds the remote in the config, and not on the actual network action. Thus if you have two remotes with two includeIfs on the remote URL it takes the config of the last defined include. Thus breaks the expectation that it is configured.

Cheers, Wesley

-- 
Wesley

Why not both?