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@xxxxxxxxxxxxx> 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 >
