A response to this: >> 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). My thought is that globbing (I’m not sure of the terminology) should be supported to the extent that it’s valid bash syntax, and breaking consistency with bash could cause more confusion than just letting the user do weird or inadvisable things with the path variable that nonetheless have entirely predictable outcomes. So, because, e.g., the following works: > elsiehupp@Alpha:~$ cat ./**/github/.gitconfig > [user] > email = github@xxxxxxxxxxxxx …one would expect, e.g., this gitconfig line to work, as well: > [include] path = ./**/github/.gitconfig For comparison, I can also do: > elsiehupp@Alpha:~$ cat ./**/**/.gitconfig > [user] > email = github@xxxxxxxxxxxxx > [user] > email = gitlab@xxxxxxxxxxxxx > [user] > email = gnome@xxxxxxxxxxxxx > [user] > email = launchpad@xxxxxxxxxxxxx > [user] > email = github@xxxxxxxxxxxxx > [user] > email = xdg@xxxxxxxxxxxxx If I pipe the above into a new ~/.gitconfig, I can then do: > elsiehupp@Alpha:~$ git config --get-all user.email > github@xxxxxxxxxxxxx > gitlab@xxxxxxxxxxxxx > gnome@xxxxxxxxxxxxx > launchpad@xxxxxxxxxxxxx > github@xxxxxxxxxxxxx > xdg@xxxxxxxxxxxxx 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: > elsiehupp@Alpha:~$ git config --get user.email > xdg@xxxxxxxxxxxxx Basically one might expect [include] to behave like cat in bash… more for consistency and predictability than anything else. None of the various cat command-line options seem particularly applicable to [include], so my commentary here mainly concerns [include] recognizing and working with path wildcards and the like along otherwise established patterns of behavior. (Now, to change my gitconfig back to the conditional includes…)
