From: Elsie Hupp <git@elsiehupp.com>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
reto@labrat.space, philipoakley@iee.email, git@vger.kernel.org
Subject: Re: Multiple --global config workspaces?
Date: Tue, 18 Oct 2022 00:02:30 -0400 [thread overview]
Message-ID: <ACFF4036-3DD1-4647-90BB-77F029326715@elsiehupp.com> (raw)
In-Reply-To: <Y0m64fHWIjZoXoTQ@coredump.intra.peff.net>
A response to this:
>> And I tried the following to no avail (despite both paths resolving when using cat):
>>
>> [includeIf "gitdir:github/"] path = ./**/github/.gitconfig
>>
>> [includeIf "gitdir:github/"] path = ./*/github/.gitconfig
>
> Right, the value of an include path expands to a single file, and we do
> not do any globbing. I suppose it would be possible to do, and we'd read
> each file in sequence. But I'm not sure I'm convinced of the utility of
> that (and again, it doesn't help the discoverability problem you had).
My thought is that globbing (I’m not sure of the terminology) should be supported to the extent that it’s valid bash syntax, and breaking consistency with bash could cause more confusion than just letting the user do weird or inadvisable things with the path variable that nonetheless have entirely predictable outcomes.
So, because, e.g., the following works:
> elsiehupp@Alpha:~$ cat ./**/github/.gitconfig
> [user]
> email = github@elsiehupp.com
…one would expect, e.g., this gitconfig line to work, as well:
> [include] path = ./**/github/.gitconfig
For comparison, I can also do:
> elsiehupp@Alpha:~$ cat ./**/**/.gitconfig
> [user]
> email = github@elsiehupp.com
> [user]
> email = gitlab@elsiehupp.com
> [user]
> email = gnome@elsiehupp.com
> [user]
> email = launchpad@elsiehupp.com
> [user]
> email = github@elsiehupp.com
> [user]
> email = xdg@elsiehupp.com
If I pipe the above into a new ~/.gitconfig, I can then do:
> elsiehupp@Alpha:~$ git config --get-all user.email
> github@elsiehupp.com
> gitlab@elsiehupp.com
> gnome@elsiehupp.com
> launchpad@elsiehupp.com
> github@elsiehupp.com
> xdg@elsiehupp.com
I don’t know off the top of my head what happens when a single variable is defined multiple times. I do get the following output, though:
> elsiehupp@Alpha:~$ git config --get user.email
> xdg@elsiehupp.com
Basically one might expect [include] to behave like cat in bash… more for consistency and predictability than anything else.
None of the various cat command-line options seem particularly applicable to [include], so my commentary here mainly concerns [include] recognizing and working with path wildcards and the like along otherwise established patterns of behavior.
(Now, to change my gitconfig back to the conditional includes…)
next prev parent reply other threads:[~2022-10-18 4:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-11 3:06 Multiple --global config workspaces? Elsie Hupp
2022-10-11 5:50 ` Junio C Hamano
2022-10-11 13:13 ` Jeff King
2022-10-11 16:55 ` Elsie Hupp
2022-10-11 18:41 ` Elsie Hupp
2022-10-14 19:39 ` Jeff King
2022-10-15 10:56 ` Matthias Aßhauer
2022-10-15 18:14 ` Jeff King
2022-10-18 4:02 ` Elsie Hupp [this message]
2022-10-18 20:53 ` Jeff King
2022-10-20 2:29 ` Elsie Hupp
2022-10-20 2:39 ` Elsie Hupp
2022-10-11 13:56 ` Philip Oakley
2022-10-11 5:51 ` Reto
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=ACFF4036-3DD1-4647-90BB-77F029326715@elsiehupp.com \
--to=git@elsiehupp.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=philipoakley@iee.email \
--cc=reto@labrat.space \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).