From: Jeff King <peff@peff.net>
To: Elsie Hupp <git@elsiehupp.com>
Cc: Junio C Hamano <gitster@pobox.com>,
reto@labrat.space, philipoakley@iee.email, git@vger.kernel.org
Subject: Re: Multiple --global config workspaces?
Date: Fri, 14 Oct 2022 15:39:13 -0400 [thread overview]
Message-ID: <Y0m64fHWIjZoXoTQ@coredump.intra.peff.net> (raw)
In-Reply-To: <03B277AB-DE33-443D-AC9C-FAB7A2F93AB3@elsiehupp.com>
On Tue, Oct 11, 2022 at 12:55:24PM -0400, Elsie Hupp wrote:
> I was using the “Git Book” documentation, not the manpage, since (a)
> the “Git Book” is more user-friendly, and (b) it’s higher on the
> DuckDuckGo results for “git config", i.e.:
>
> https://www.git-scm.com/book/en/v2/Customizing-Git-Git-Configuration
I'm not too surprised that conditional includes aren't mentioned there.
The last major revision of the book was the second edition in 2014, and
conditional includes are from 2017. (Includes in general were from 2012,
but I think they were pretty niche back then).
> So in summary it seems like a big part the issue I had is that the
> documentation for conditional includes has somewhat lacking SEO, i.e.
> if someone is familiar with the --global config keywords and googles
> that, they are unlikely to find the section for conditional includes.
> And, additionally, conditional includes are a new enough feature that
> they don’t appear in the higher-ranking web-based manpages, neither of
> which display the version of Git they pertain to. (Maybe someone could
> poke them about this, but I’m not sure the best way of doing so.)
I'm not sure who to poke about updating those other sites (or even how
old they are). The git-scm.com is maintained by Git folks, and always
has documentation for the latest version. It also shows up at the top of
Google results for me, but given how personalization works there, I've
no clue how common that is.
As you noted, git-scm.com also carries the book content. They do take
community input, but I don't think there are many (any?) regular Git
developers who contribute much there. Looks like you opened an issue in
the progit2 repository, which is the best next step there.
> As an aside, looking through the full documentation I see that I can also do:
>
> [includeIf "hasconfig:remote.*.url:https://github.com/**”] path = ./Repositories/github/.gitconfig
> [includeIf "hasconfig:remote.*.url:https://gitlab.com/**”] path = ./Repositories/gitlab/.gitconfig
Ah, I forgot about that one. Note that it's new-ish, only in v2.36 and
higher. I agree it's probably a better fit for your use case.
> Something more consistent with my initial use case might be a
> hypothetical feature like the following (apologies for dubious
> syntax):
>
> [user "gitdir:github/"]
> email = "elsiehupp.github@example.com"
The trouble there is that the "subsection" (the part in quotes) already
has a meaning for many keys. E.g.,
[remote "foo"]
url = ...whatever...
couldn't be conditional. Obviously we could add new syntax to solve
this, but one of the design goals of both the original include feature,
as well as the conditional includes, was to remain syntactically
compatible with existing parsers. But it is an unfortunate tradeoff that
it's a bit clunkier than it otherwise could be.
> I also tried:
>
> [include] path = $GIT_COMMON_DIR/../.gitconfig
>
> …only to discover that $GIT_COMMON_DIR is not set automatically. Is
> there some way of automatically describing a path relative to any
> given cloned Git repository?
No, I don't think there's a way of doing that right now. But I agree it
could work and would retain syntactic compatibility. I wonder if it's
worth it, though. The result is potentially fragile (e.g., if you had
github/foo/repo.git it would need to use more dot-dot elements), and it
doesn't really solve the most obvious stumbling block, which is that you
were looking for conditional variables, not conditional includes.
> 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).
-Peff
next prev parent reply other threads:[~2022-10-14 19: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 [this message]
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
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=Y0m64fHWIjZoXoTQ@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@elsiehupp.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--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).