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@xxxxxxxxxxx" 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
