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: Wed, 19 Oct 2022 22:39:45 -0400 [thread overview]
Message-ID: <2A64CF44-0AE5-497D-85C7-F625B51EA28F@elsiehupp.com> (raw)
In-Reply-To: <90F9456A-6ABC-4555-8127-FF2DB0449EF1@elsiehupp.com>
I might also mention recursive globbing à la bash globstar, as described here:
https://unix.stackexchange.com/questions/49913/recursive-glob
…but that’s getting quite a bit into the weeds (not to mention exceeding my personal knowledge of bash).
> On Oct 19, 2022, at 10:29 PM, Elsie Hupp <git@elsiehupp.com> wrote:
>
>> The expansion of the glob is done by the shell. But it is "cat" which is
>> happy to receive multiple files as input. But many other commands are
>> not, and include.path is not.
>>
>> None of which is to say you're wrong to think of it this way. It's a
>> perfectly valid mental model. It just happens not to be the mental model
>> we used when implementing it.
>
> The only reason I thought of trying it in the first place is that while reading the git-config documentation, I saw that [include]:gitdir uses implicit globbing:
>
> https://git-scm.com/docs/git-config#Documentation/git-config.txt-codegitdircode
>
>> • If the pattern does not start with either ~/, ./ or /, **/ will be automatically prepended. For example, the pattern foo/bar becomes **/foo/bar and would match /any/path/to/foo/bar.
>> • If the pattern ends with /, ** will be automatically added. For example, the pattern foo/ becomes foo/**. In other words, it matches "foo" and everything inside, recursively.
>
> Like literally I did not think to try the wildcard characters with [include] until the mentions of [include]:gitdir, [include]:onbranch, and [include]:hasconfig:remote.*.url suggested it to me.
>
> Admittedly, the examples here are for *implicit* glowing, rather than *explicit* globbing, but this support in one way or another does create a stronger proximate case for consistency than cat does.
>
>> 1. I'd be more convinced by a concrete use case. It sounds like
>> conditional includes were the real sticking point for yours. Maybe
>> somebody wants to do include.path on ".gitconfig.d/*" or something?
>> I dunno.
>
> Basically what I would like as a concrete example is the ability to specify the path, e.g., ~/Repositories/github/.gitconfig without having to specify the name “Repositories”, as other users might prefer, e.g., ~/Projects/github/.gitconfig instead.
>
>>> 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:
>>
>> It depends on the variable. Most single-value options in Git are "last
>> one wins", but some are lists (e.g., remote.*.fetch). We also hold
>> config values for other porcelain scripts whose semantics we may not
>> even know ourselves. There are options to "git config" for specifying
>> how to handle these (e.g., --get-all).
>
> I mean this is where the desired behavior would have to be defined. From my somewhat ignorant position, “last one wins” does seem reasonable in the case of, say, user.email.
>
>> if somebody wants to go to the trouble to implement
>
> Yeah this somebody is almost certainly not going to be me, considering my complete and utter unfamiliarity with the codebase, among other things. 😬
>
> As for proceeding, I think what I can do personally is submit a draft pull request to the Git Book repository with instructions for how to accomplish my own use case as well as, say, the personal/school/work use case with the functionality that already exists, and then based on how that goes things could go from there…?
>
> Best,
> Elsie
>
next prev parent reply other threads:[~2022-10-20 2:39 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
2022-10-18 20:53 ` Jeff King
2022-10-20 2:29 ` Elsie Hupp
2022-10-20 2:39 ` Elsie Hupp [this message]
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=2A64CF44-0AE5-497D-85C7-F625B51EA28F@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).