git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Mar 28, 2026, 02:03 UTC
Message-ID
<20260328020327.GB621762@coredump.intra.peff.net>
In-Reply-To
<a4a03bae-b987-4b21-a7fd-fbdb9d832430@opperschaap.net>
On Fri, Mar 27, 2026 at 08:43:07PM -0400, Wesley wrote:
Show 17 quoted lines
> > 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.

Yes, it's going to be per-local-repo. I had assumed you were in a situation where you were defining these setups at the global level, and each local repo will want to use them or not. I.e., something like this:

  [set up once]
  $ git config -f ~/.gitconfig-foo core.sshCommand "ssh -i whatever"
  $ git config --global includeIf.hasconfig:remote.*.url:example.com:foo/**.path .gitconfig-foo
  [and now we'd use it in this repo]
  $ git clone example.com:foo/repo.git
  [but not this one]
  $ git clone example.com:bar/repo.git

If you have remotes for both "foo/repo.git" and "bar/repo.git" configured in one local repo, then yes, it will always apply the config.

If you really want per-connection config, I'm still not quite convinced that you aren't better off defining host sections in your ssh config. That covers all options that ssh knows about (not just ones we teach Git about), and you can still apply it automatically from ~/.gitconfig using insteadOf. Something like:

  git config --global foo.example.com:foo/.insteadOf example.com:foo/
and then defining a foo.example.com block in your ~/.ssh/config.
-Peff
Previous: WesleyNext: Wesley
Message 12 of 24 in “Add support for per-remote and per-namespace SSH options”
  1. 0/3 Add support for per-remote and per-namespace SSH optionsWesley Schwengle, Mar 26, 2026
  2. 1/3 connect: Rename name to command in connect_git()Wesley Schwengle, Mar 26, 2026
  3. Jeff KingMar 27, 2026
  4. WesleyMar 28, 2026
  5. Jeff KingMar 28, 2026
  6. WesleyMar 28, 2026
  7. 2/3 connect: Add transport->remote->name to git_connect()Wesley Schwengle, Mar 26, 2026
  8. Jeff KingMar 27, 2026
  9. 3/3 connect: Add support for per-remote and per-namespace SSH optionsWesley Schwengle, Mar 26, 2026
  10. Jeff KingMar 27, 2026
  11. WesleyMar 28, 2026
  12. Jeff KingMar 28, 2026
  13. WesleyMar 28, 2026
  14. Johannes SixtMar 27, 2026
  15. WesleyMar 27, 2026
  16. Junio C HamanoMar 27, 2026
  17. WesleyMar 27, 2026
  18. brian m. carlsonMar 27, 2026
  19. WesleyMar 28, 2026
  20. Johannes SixtMar 28, 2026
  21. WesleyMar 28, 2026
  22. Ben KnobleMar 29, 2026
  23. brian m. carlsonMar 27, 2026
  24. Junio C HamanoMar 27, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.