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:29:42 -0400 [thread overview]
Message-ID: <90F9456A-6ABC-4555-8127-FF2DB0449EF1@elsiehupp.com> (raw)
In-Reply-To: <Y08SRgwIvDcsWF0Z@coredump.intra.peff.net>
> 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:30 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 [this message]
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=90F9456A-6ABC-4555-8127-FF2DB0449EF1@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).