{"thread":{"id":"58598","subject":"Multiple --global config workspaces?","startedAt":"2022-10-11T03:16:13Z","lastAt":"2022-10-20T02:39:51Z","messageCount":14,"participants":["Elsie Hupp","Junio C Hamano","Reto","Jeff King","Philip Oakley","Matthias Aßhauer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"464586","messageId":"C4E3A512-2E2C-4EA5-9F2E-3662BCF0F165@elsiehupp.com","threadId":"58598","inReplyTo":null,"subject":"Multiple --global config workspaces?","fromName":"Elsie Hupp","fromEmail":"git@elsiehupp.com","sentAt":"2022-10-11T03:06:32Z","receivedAt":"2022-10-11T03:16:13Z","isPatch":false,"sender":{"key":"git@elsiehupp.com","avatar":null},"body":"Hi Git Mailing List,\n\nThe way I personally use Git has a slight inconvenience: as far as I can tell, there is no way to define multiple git config --global workspaces in a single Unix account. \n\nI structure my cloned repositories based on the remote host, e.g.:\n\n~/Repositories/github/cloned-repository-name\n~/Repositories/gitlab/other-cloned-repository-name\n\n…and I sign my git commits for each remote host using an email address and signing key specific to that host.\n\nI imagine many people have similar arrangements for the purpose of separating, say, work projects from personal projects.\n\nBefore I started using this workspace arrangement, I was able to do the following:\n\n$ git config --global user.name \"Elsie Hupp\"\n$ git config --global user.email \"elsiehupp@example.com\"\n\nHowever, now that I use different signing identities for different remote hosts, I have to set up my Git identity every single time I clone a repository, and this repetitiveness is the slight inconvenience I refer to above.\n\nWhat might possibly help in this situation could be if I could have the global ~/.gitconfig somehow delegate to separate .gitconfig files in each of the workspace folders I have set up, e.g.:\n\n~/Repositories/github/.gitconfig\n~/Repositories/gitlab/.gitconfig\n\n…and then have git config --global in, e.g., ~/Repositories/github/cloned-repository-name apply to all cloned repositories in ~/Repositories/github but not to cloned repositories in ~/Repositories/gitlab.\n\n(Obviously there are other ways this could be implemented, but this is the one that immediately came to mind.)\n\nHow feasible would it be to implement multiple --global config workspaces with functionality along these lines? And what other considerations and issues might there be with doing so?\n\nAnyway, thank you for your time and attention.\n\nSincerely,\nElsie Hupp"},{"id":"464589","messageId":"xmqqwn96x61t.fsf@gitster.g","threadId":"58598","inReplyTo":"C4E3A512-2E2C-4EA5-9F2E-3662BCF0F165@elsiehupp.com","subject":"Re: Multiple --global config workspaces?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-11T05:50:22Z","receivedAt":"2022-10-11T05:50:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elsie Hupp <git@elsiehupp.com> writes:\n\n> I structure my cloned repositories based on the remote host, e.g.:\n>\n> ~/Repositories/github/cloned-repository-name\n> ~/Repositories/gitlab/other-cloned-repository-name\n\nThe above is by definition not \"global\" (aka \"per user\").\n\n\"--global\" is for things that are of your personal preference, not\n\"when I am working on this project, these settings apply\" (which is\nsuitable for \"per repository\").\n\nWhat you want is a way to say \"when I am working on these projects,\nthese settings apply\".\n\nOne way to do this would be to have\n\n\t[includeIf \"gitdir:~/Repositories/github/\"] path = $HOME/.githubconfig\n\t[includeIf \"gitdir:~/Repositories/gitlab/\"] path = $HOME/.gitlabconfig\n\nin $HOME/.gitconfig and then write in these two extra files that are\nconditionally included whatever settings you want to use for any and\nall repositories that come from GitHub or GitLab.\n\n$ git help config\n\nand look for Conditional includes, perhaps?\n\n\n"},{"id":"464590","messageId":"20221011055130.gvoh44rbulg3f4jn@feather","threadId":"58598","inReplyTo":"C4E3A512-2E2C-4EA5-9F2E-3662BCF0F165@elsiehupp.com","subject":"Re: Multiple --global config workspaces?","fromName":"Reto","fromEmail":"reto@labrat.space","sentAt":"2022-10-11T05:51:30Z","receivedAt":"2022-10-11T05:58:09Z","isPatch":false,"sender":{"key":"reto@labrat.space","avatar":null},"body":"On Mon, Oct 10, 2022 at 11:06:32PM -0400, Elsie Hupp wrote:\n> What might possibly help in this situation could be if I could have the global ~/.gitconfig somehow delegate to separate .gitconfig files in each of the workspace folders I have set up, e.g.:\n\n> ~/Repositories/github/.gitconfig\n> ~/Repositories/gitlab/.gitconfig\n\nThat already exists, git-config(1), look for \"Conditional includes\"\nThat way you can do it per top level folder or whatever makes sense for\nyou.\n\nExamples:\n\n; include for all repositories inside /path/to/group\n[includeIf \"gitdir:/path/to/group/\"]\n\t   path = /path/to/foo.inc\n\n; include for all repositories inside $HOME/to/group\n[includeIf \"gitdir:~/to/group/\"]\n\t   path = /path/to/foo.inc\n"},{"id":"464606","messageId":"Y0Vr/4IeA236nxzF@coredump.intra.peff.net","threadId":"58598","inReplyTo":"xmqqwn96x61t.fsf@gitster.g","subject":"Re: Multiple --global config workspaces?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-10-11T13:13:35Z","receivedAt":"2022-10-11T13:13:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 10, 2022 at 10:50:22PM -0700, Junio C Hamano wrote:\n\n> One way to do this would be to have\n> \n> \t[includeIf \"gitdir:~/Repositories/github/\"] path = $HOME/.githubconfig\n> \t[includeIf \"gitdir:~/Repositories/gitlab/\"] path = $HOME/.gitlabconfig\n> \n> in $HOME/.gitconfig and then write in these two extra files that are\n> conditionally included whatever settings you want to use for any and\n> all repositories that come from GitHub or GitLab.\n\nI was about to write the same response. :) One small correction, though:\nwe don't expand $HOME in include paths. You can use \"~\", but easier\nstill is that non-absolute includes are relative to the including file.\nRelative paths in includes are relative to the including file. So you\ncan just write \".githubconfig\", etc, and we'll expect them adjacent to\n$HOME/.gitconfig (or the xdg path if you use that, I guess).\n\n-Peff\n"},{"id":"464612","messageId":"85046d94-fa83-db7b-df64-27cf928fd08e@iee.email","threadId":"58598","inReplyTo":"xmqqwn96x61t.fsf@gitster.g","subject":"Re: Multiple --global config workspaces?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2022-10-11T13:56:26Z","receivedAt":"2022-10-11T13:56:34Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 11/10/2022 06:50, Junio C Hamano wrote:\n> Elsie Hupp <git@elsiehupp.com> writes:\n>\n>> I structure my cloned repositories based on the remote host, e.g.:\n>>\n>> ~/Repositories/github/cloned-repository-name\n>> ~/Repositories/gitlab/other-cloned-repository-name\n> The above is by definition not \"global\" (aka \"per user\").\n>\n> \"--global\" is for things that are of your personal preference, not\n> \"when I am working on this project, these settings apply\" (which is\n> suitable for \"per repository\").\n>\n> What you want is a way to say \"when I am working on these projects,\n> these settings apply\".\n>\n> One way to do this would be to have\n>\n> \t[includeIf \"gitdir:~/Repositories/github/\"] path = $HOME/.githubconfig\n> \t[includeIf \"gitdir:~/Repositories/gitlab/\"] path = $HOME/.gitlabconfig\n>\n> in $HOME/.gitconfig and then write in these two extra files that are\n> conditionally included whatever settings you want to use for any and\n> all repositories that come from GitHub or GitLab.\n>\n> $ git help config\n>\n> and look for Conditional includes, perhaps?\n>\n>\nThis use of \"IncludeIf\" for the Home/work case also came up in a recent\nGit for Windows discussion\nhttps://github.com/git-for-windows/git/discussions/4058\n\nThat discussion was about the trickiness of quoting when on the\ndifferent Windows terminals/shells as the config string gets passed\naround (IIUC).\n\n--\nPhilip\n"},{"id":"464621","messageId":"03B277AB-DE33-443D-AC9C-FAB7A2F93AB3@elsiehupp.com","threadId":"58598","inReplyTo":"Y0Vr/4IeA236nxzF@coredump.intra.peff.net","subject":"Re: Multiple --global config workspaces?","fromName":"Elsie Hupp","fromEmail":"git@elsiehupp.com","sentAt":"2022-10-11T16:55:24Z","receivedAt":"2022-10-11T16:55:53Z","isPatch":false,"sender":{"key":"git@elsiehupp.com","avatar":null},"body":"Hi Junio, Reto, Jeff, Philip, et al,\n\nCool, thanks!\n\nI 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.:\n\nhttps://www.git-scm.com/book/en/v2/Customizing-Git-Git-Configuration\n\nEven then, I don’t see includeIf in the first two web-based versions of the manpage for the DuckDuckGo query \"man git-config\":\n\nhttps://linux.die.net/man/1/git-config\nhttps://manpages.org/git-config\n\nThough includeIf does appear in the manpage on my local system, as well as in the web-based Arch manpage (which is the fifth result):\n\nhttps://man.archlinux.org/man/git-config.1\n\nAnd includeIf does appear in the official documentation (which is the first DuckDuckGo result for \"man git-config”—I much prefer web mirrors to using man in the terminal):\n\nhttps://git-scm.com/docs/git-config#_conditional_includes\n\nSo 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.)\n\nAs an aside, looking through the full documentation I see that I can also do:\n\n[includeIf \"hasconfig:remote.*.url:https://github.com/**”] path = ./Repositories/github/.gitconfig\n[includeIf \"hasconfig:remote.*.url:https://gitlab.com/**”] path =  ./Repositories/gitlab/.gitconfig\n\nAnd, conveniently, [includeIf \"gitdir:github/“] also expands to [includeIf “gitdir:**/github/“], so I don’t have to specify [includeIf \"gitdir:~/Repositories/github/“]. (I’m not sure how to represent the trailing slash in bash syntax, but it helps, too!)\n\nSomething more consistent with my initial use case might be a hypothetical feature like the following (apologies for dubious syntax):\n\n[user \"gitdir:github/\"]\n\temail = \"elsiehupp.github@example.com\"\n\nOr something like:\n\nif \"gitdir:gitlab/\" email = \"elsiehupp.gitlab@example.com”\n\nIn other words, part of the discoverability issue is that I wasn’t looking for a conditional _include_ so much as a conditional statement more generally.\n\nI also tried:\n\n[include] path = $GIT_COMMON_DIR/../.gitconfig\n\n…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?\n\nAnd I tried the following to no avail (despite both paths resolving when using cat):\n\n[includeIf \"gitdir:github/\"] path = ./**/github/.gitconfig\n\n[includeIf \"gitdir:github/\"] path = ./*/github/.gitconfig\n\nSo it would be nice if in addition to being able to use bash wildcards in [includeIf “gitdir”] one could use bash wildcards in inclusion paths, as well.\n\nI guess for the time being what I’ll stick with is this:\n\n[includeIf \"gitdir:github/\"] path = ./Repositories/github/.gitconfig\n[includeIf \"gitdir:gitlab/\"] path = ./Repositories/gitlab/.gitconfig\n\nBest,\nElsie Hupp\n\n\n> On Oct 11, 2022, at 9:56 AM, Philip Oakley <philipoakley@iee.email> wrote:\n> \n> On 11/10/2022 06:50, Junio C Hamano wrote:\n>> Elsie Hupp <git@elsiehupp.com> writes:\n>> \n>>> I structure my cloned repositories based on the remote host, e.g.:\n>>> \n>>> ~/Repositories/github/cloned-repository-name\n>>> ~/Repositories/gitlab/other-cloned-repository-name\n>> The above is by definition not \"global\" (aka \"per user\").\n>> \n>> \"--global\" is for things that are of your personal preference, not\n>> \"when I am working on this project, these settings apply\" (which is\n>> suitable for \"per repository\").\n>> \n>> What you want is a way to say \"when I am working on these projects,\n>> these settings apply\".\n>> \n>> One way to do this would be to have\n>> \n>> \t[includeIf \"gitdir:~/Repositories/github/\"] path = $HOME/.githubconfig\n>> \t[includeIf \"gitdir:~/Repositories/gitlab/\"] path = $HOME/.gitlabconfig\n>> \n>> in $HOME/.gitconfig and then write in these two extra files that are\n>> conditionally included whatever settings you want to use for any and\n>> all repositories that come from GitHub or GitLab.\n>> \n>> $ git help config\n>> \n>> and look for Conditional includes, perhaps?\n>> \n>> \n> This use of \"IncludeIf\" for the Home/work case also came up in a recent\n> Git for Windows discussion\n> https://github.com/git-for-windows/git/discussions/4058\n> \n> That discussion was about the trickiness of quoting when on the\n> different Windows terminals/shells as the config string gets passed\n> around (IIUC).\n> \n> --\n> Philip\n\n\n\n> On Oct 11, 2022, at 1:50 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> \n> Elsie Hupp <git@elsiehupp.com> writes:\n> \n>> I structure my cloned repositories based on the remote host, e.g.:\n>> \n>> ~/Repositories/github/cloned-repository-name\n>> ~/Repositories/gitlab/other-cloned-repository-name\n> \n> The above is by definition not \"global\" (aka \"per user\").\n> \n> \"--global\" is for things that are of your personal preference, not\n> \"when I am working on this project, these settings apply\" (which is\n> suitable for \"per repository\").\n> \n> What you want is a way to say \"when I am working on these projects,\n> these settings apply\".\n> \n> One way to do this would be to have\n> \n> \t[includeIf \"gitdir:~/Repositories/github/\"] path = $HOME/.githubconfig\n> \t[includeIf \"gitdir:~/Repositories/gitlab/\"] path = $HOME/.gitlabconfig\n> \n> in $HOME/.gitconfig and then write in these two extra files that are\n> conditionally included whatever settings you want to use for any and\n> all repositories that come from GitHub or GitLab.\n> \n> $ git help config\n> \n> and look for Conditional includes, perhaps?\n\n\n> On Oct 11, 2022, at 1:51 AM, Reto <reto@labrat.space> wrote:\n> \n> That already exists, git-config(1), look for \"Conditional includes\"\n> That way you can do it per top level folder or whatever makes sense for\n> you.\n> \n> Examples:\n> \n> ; include for all repositories inside /path/to/group\n> [includeIf \"gitdir:/path/to/group/\"]\n> \t   path = /path/to/foo.inc\n> \n> ; include for all repositories inside $HOME/to/group\n> [includeIf \"gitdir:~/to/group/\"]\n> \t   path = /path/to/foo.inc\n\n\n> On Oct 11, 2022, at 9:13 AM, Jeff King <peff@peff.net> wrote:\n> \n> On Mon, Oct 10, 2022 at 10:50:22PM -0700, Junio C Hamano wrote:\n> \n>> One way to do this would be to have\n>> \n>> \t[includeIf \"gitdir:~/Repositories/github/\"] path = $HOME/.githubconfig\n>> \t[includeIf \"gitdir:~/Repositories/gitlab/\"] path = $HOME/.gitlabconfig\n>> \n>> in $HOME/.gitconfig and then write in these two extra files that are\n>> conditionally included whatever settings you want to use for any and\n>> all repositories that come from GitHub or GitLab.\n> \n> I was about to write the same response. :) One small correction, though:\n> we don't expand $HOME in include paths. You can use \"~\", but easier\n> still is that non-absolute includes are relative to the including file.\n> Relative paths in includes are relative to the including file. So you\n> can just write \".githubconfig\", etc, and we'll expect them adjacent to\n> $HOME/.gitconfig (or the xdg path if you use that, I guess).\n> \n> -Peff\n\n"},{"id":"464628","messageId":"909C9446-F04D-4037-B12D-C97A68EC5AB3@elsiehupp.com","threadId":"58598","inReplyTo":"03B277AB-DE33-443D-AC9C-FAB7A2F93AB3@elsiehupp.com","subject":"Re: Multiple --global config workspaces?","fromName":"Elsie Hupp","fromEmail":"git@elsiehupp.com","sentAt":"2022-10-11T18:41:53Z","receivedAt":"2022-10-11T18:41:58Z","isPatch":false,"sender":{"key":"git@elsiehupp.com","avatar":null},"body":"I just opened an issue on the “Git Book” repository suggesting the addition of a section discussing [includeIf], if anyone here would like to comment there:\n\nhttps://github.com/progit/progit2/issues/1801\n\n> On Oct 11, 2022, at 12:55 PM, Elsie Hupp <git@elsiehupp.com> wrote:\n> \n> Hi Junio, Reto, Jeff, Philip, et al,\n> \n> Cool, thanks!\n> \n> 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.:\n> \n> https://www.git-scm.com/book/en/v2/Customizing-Git-Git-Configuration\n> \n> Even then, I don’t see includeIf in the first two web-based versions of the manpage for the DuckDuckGo query \"man git-config\":\n> \n> https://linux.die.net/man/1/git-config\n> https://manpages.org/git-config\n> \n> Though includeIf does appear in the manpage on my local system, as well as in the web-based Arch manpage (which is the fifth result):\n> \n> https://man.archlinux.org/man/git-config.1\n> \n> And includeIf does appear in the official documentation (which is the first DuckDuckGo result for \"man git-config”—I much prefer web mirrors to using man in the terminal):\n> \n> https://git-scm.com/docs/git-config#_conditional_includes\n> \n> 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.)\n> \n> As an aside, looking through the full documentation I see that I can also do:\n> \n> [includeIf \"hasconfig:remote.*.url:https://github.com/**”] path = ./Repositories/github/.gitconfig\n> [includeIf \"hasconfig:remote.*.url:https://gitlab.com/**”] path =  ./Repositories/gitlab/.gitconfig\n> \n> And, conveniently, [includeIf \"gitdir:github/“] also expands to [includeIf “gitdir:**/github/“], so I don’t have to specify [includeIf \"gitdir:~/Repositories/github/“]. (I’m not sure how to represent the trailing slash in bash syntax, but it helps, too!)\n> \n> Something more consistent with my initial use case might be a hypothetical feature like the following (apologies for dubious syntax):\n> \n> [user \"gitdir:github/\"]\n> \temail = \"elsiehupp.github@example.com\"\n> \n> Or something like:\n> \n> if \"gitdir:gitlab/\" email = \"elsiehupp.gitlab@example.com”\n> \n> In other words, part of the discoverability issue is that I wasn’t looking for a conditional _include_ so much as a conditional statement more generally.\n> \n> I also tried:\n> \n> [include] path = $GIT_COMMON_DIR/../.gitconfig\n> \n> …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?\n> \n> And I tried the following to no avail (despite both paths resolving when using cat):\n> \n> [includeIf \"gitdir:github/\"] path = ./**/github/.gitconfig\n> \n> [includeIf \"gitdir:github/\"] path = ./*/github/.gitconfig\n> \n> So it would be nice if in addition to being able to use bash wildcards in [includeIf “gitdir”] one could use bash wildcards in inclusion paths, as well.\n> \n> I guess for the time being what I’ll stick with is this:\n> \n> [includeIf \"gitdir:github/\"] path = ./Repositories/github/.gitconfig\n> [includeIf \"gitdir:gitlab/\"] path = ./Repositories/gitlab/.gitconfig\n> \n> Best,\n> Elsie Hupp\n\n"},{"id":"464980","messageId":"Y0m64fHWIjZoXoTQ@coredump.intra.peff.net","threadId":"58598","inReplyTo":"03B277AB-DE33-443D-AC9C-FAB7A2F93AB3@elsiehupp.com","subject":"Re: Multiple --global config workspaces?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-10-14T19:39:13Z","receivedAt":"2022-10-14T19:39:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 11, 2022 at 12:55:24PM -0400, Elsie Hupp wrote:\n\n> I was using the “Git Book” documentation, not the manpage, since (a)\n> the “Git Book” is more user-friendly, and (b) it’s higher on the\n> DuckDuckGo results for “git config\", i.e.:\n> \n> https://www.git-scm.com/book/en/v2/Customizing-Git-Git-Configuration\n\nI'm not too surprised that conditional includes aren't mentioned there.\nThe last major revision of the book was the second edition in 2014, and\nconditional includes are from 2017. (Includes in general were from 2012,\nbut I think they were pretty niche back then).\n\n> So in summary it seems like a big part the issue I had is that the\n> documentation for conditional includes has somewhat lacking SEO, i.e.\n> if someone is familiar with the --global config keywords and googles\n> that, they are unlikely to find the section for conditional includes.\n> And, additionally, conditional includes are a new enough feature that\n> they don’t appear in the higher-ranking web-based manpages, neither of\n> which display the version of Git they pertain to. (Maybe someone could\n> poke them about this, but I’m not sure the best way of doing so.)\n\nI'm not sure who to poke about updating those other sites (or even how\nold they are). The git-scm.com is maintained by Git folks, and always\nhas documentation for the latest version. It also shows up at the top of\nGoogle results for me, but given how personalization works there, I've\nno clue how common that is.\n\nAs you noted, git-scm.com also carries the book content. They do take\ncommunity input, but I don't think there are many (any?) regular Git\ndevelopers who contribute much there. Looks like you opened an issue in\nthe progit2 repository, which is the best next step there.\n\n> As an aside, looking through the full documentation I see that I can also do:\n> \n> [includeIf \"hasconfig:remote.*.url:https://github.com/**”] path = ./Repositories/github/.gitconfig\n> [includeIf \"hasconfig:remote.*.url:https://gitlab.com/**”] path =  ./Repositories/gitlab/.gitconfig\n\nAh, I forgot about that one. Note that it's new-ish, only in v2.36 and\nhigher. I agree it's probably a better fit for your use case.\n\n> Something more consistent with my initial use case might be a\n> hypothetical feature like the following (apologies for dubious\n> syntax):\n> \n> [user \"gitdir:github/\"]\n> \temail = \"elsiehupp.github@example.com\"\n\nThe trouble there is that the \"subsection\" (the part in quotes) already\nhas a meaning for many keys. E.g.,\n\n  [remote \"foo\"]\n  url = ...whatever...\n\ncouldn't be conditional. Obviously we could add new syntax to solve\nthis, but one of the design goals of both the original include feature,\nas well as the conditional includes, was to remain syntactically\ncompatible with existing parsers. But it is an unfortunate tradeoff that\nit's a bit clunkier than it otherwise could be.\n\n> I also tried:\n> \n> [include] path = $GIT_COMMON_DIR/../.gitconfig\n> \n> …only to discover that $GIT_COMMON_DIR is not set automatically. Is\n> there some way of automatically describing a path relative to any\n> given cloned Git repository?\n\nNo, I don't think there's a way of doing that right now. But I agree it\ncould work and would retain syntactic compatibility. I wonder if it's\nworth it, though. The result is potentially fragile (e.g., if you had\ngithub/foo/repo.git it would need to use more dot-dot elements), and it\ndoesn't really solve the most obvious stumbling block, which is that you\nwere looking for conditional variables, not conditional includes.\n\n> And I tried the following to no avail (despite both paths resolving when using cat):\n> \n> [includeIf \"gitdir:github/\"] path = ./**/github/.gitconfig\n> \n> [includeIf \"gitdir:github/\"] path = ./*/github/.gitconfig\n\nRight, the value of an include path expands to a single file, and we do\nnot do any globbing. I suppose it would be possible to do, and we'd read\neach file in sequence. But I'm not sure I'm convinced of the utility of\nthat (and again, it doesn't help the discoverability problem you had).\n\n-Peff\n"},{"id":"465015","messageId":"AM0PR04MB60197E29A9D11F3689C03225A5279@AM0PR04MB6019.eurprd04.prod.outlook.com","threadId":"58598","inReplyTo":"Y0m64fHWIjZoXoTQ@coredump.intra.peff.net","subject":"Re: Multiple --global config workspaces?","fromName":"Matthias Aßhauer","fromEmail":"mha1993@live.de","sentAt":"2022-10-15T10:56:38Z","receivedAt":"2022-10-15T10:56:48Z","isPatch":false,"sender":{"key":"mha1993@live.de","avatar":"https://avatars.githubusercontent.com/u/6178234?v=4"},"body":"\n\nOn Fri, 14 Oct 2022, Jeff King wrote:\n\n> I'm not sure who to poke about updating those other sites (or even how\n> old they are). The git-scm.com is maintained by Git folks, and always\n> has documentation for the latest version. It also shows up at the top of\n> Google results for me, but given how personalization works there, I've\n> no clue how common that is.\n\ndie.net is often quite high in the google results for me and from \nexperience seems to be a common source when looking up man pages online.\nTheir git related man pages seem to be roughly from around Git 1.7.5. \nThey do have a contact email at the bottom of their homepage. I'll try to \npoke them.\n\nBest regards\n\nMatthias\n"},{"id":"465025","messageId":"Y0r4lfRRNeVA5mU2@coredump.intra.peff.net","threadId":"58598","inReplyTo":"AM0PR04MB60197E29A9D11F3689C03225A5279@AM0PR04MB6019.eurprd04.prod.outlook.com","subject":"Re: Multiple --global config workspaces?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-10-15T18:14:45Z","receivedAt":"2022-10-15T18:14:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 15, 2022 at 12:56:38PM +0200, Matthias Aßhauer wrote:\n\n> die.net is often quite high in the google results for me and from experience\n> seems to be a common source when looking up man pages online.\n> Their git related man pages seem to be roughly from around Git 1.7.5. They\n> do have a contact email at the bottom of their homepage. I'll try to poke\n> them.\n\nThanks for doing so. 1.7.5 is really quite old (2011!).\n\n-Peff\n"},{"id":"465171","messageId":"ACFF4036-3DD1-4647-90BB-77F029326715@elsiehupp.com","threadId":"58598","inReplyTo":"Y0m64fHWIjZoXoTQ@coredump.intra.peff.net","subject":"Re: Multiple --global config workspaces?","fromName":"Elsie Hupp","fromEmail":"git@elsiehupp.com","sentAt":"2022-10-18T04:02:30Z","receivedAt":"2022-10-18T04:02:42Z","isPatch":false,"sender":{"key":"git@elsiehupp.com","avatar":null},"body":"A response to this:\n\n>> And I tried the following to no avail (despite both paths resolving when using cat):\n>> \n>> [includeIf \"gitdir:github/\"] path = ./**/github/.gitconfig\n>> \n>> [includeIf \"gitdir:github/\"] path = ./*/github/.gitconfig\n> \n> Right, the value of an include path expands to a single file, and we do\n> not do any globbing. I suppose it would be possible to do, and we'd read\n> each file in sequence. But I'm not sure I'm convinced of the utility of\n> that (and again, it doesn't help the discoverability problem you had).\n\nMy 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.\n\nSo, because, e.g., the following works:\n\n> elsiehupp@Alpha:~$ cat ./**/github/.gitconfig\n> [user]\n> \temail = github@elsiehupp.com\n\n…one would expect, e.g., this gitconfig line to work, as well:\n\n> [include] path = ./**/github/.gitconfig\n\n\nFor comparison, I can also do:\n\n> elsiehupp@Alpha:~$ cat ./**/**/.gitconfig\n> [user]\n> \temail = github@elsiehupp.com\n> [user]\n> \temail = gitlab@elsiehupp.com\n> [user]\n> \temail = gnome@elsiehupp.com\n> [user]\n> \temail = launchpad@elsiehupp.com\n> [user]\n> \temail = github@elsiehupp.com\n> [user]\n> \temail = xdg@elsiehupp.com\n\nIf I pipe the above into a new ~/.gitconfig, I can then do:\n\n> elsiehupp@Alpha:~$ git config --get-all user.email\n> github@elsiehupp.com\n> gitlab@elsiehupp.com\n> gnome@elsiehupp.com\n> launchpad@elsiehupp.com\n> github@elsiehupp.com\n> xdg@elsiehupp.com\n\nI 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:\n\n> elsiehupp@Alpha:~$ git config --get user.email\n> xdg@elsiehupp.com\n\nBasically one might expect [include] to behave like cat in bash… more for consistency and predictability than anything else.\n\nNone 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.\n\n(Now, to change my gitconfig back to the conditional includes…)\n\n"},{"id":"465224","messageId":"Y08SRgwIvDcsWF0Z@coredump.intra.peff.net","threadId":"58598","inReplyTo":"ACFF4036-3DD1-4647-90BB-77F029326715@elsiehupp.com","subject":"Re: Multiple --global config workspaces?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-10-18T20:53:26Z","receivedAt":"2022-10-18T20:53:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 18, 2022 at 12:02:30AM -0400, Elsie Hupp wrote:\n\n> > Right, the value of an include path expands to a single file, and we do\n> > not do any globbing. I suppose it would be possible to do, and we'd read\n> > each file in sequence. But I'm not sure I'm convinced of the utility of\n> > that (and again, it doesn't help the discoverability problem you had).\n> \n> My thought is that globbing (I’m not sure of the terminology) should\n> be supported to the extent that it’s valid bash syntax, and breaking\n> consistency with bash could cause more confusion than just letting the\n> user do weird or inadvisable things with the path variable that\n> nonetheless have entirely predictable outcomes.\n\nI'm not sure I buy this. We are not otherwise consistent with bash for\nvalue expansion. For instance, we don't allow variable expansion like\n$HOME. The only thing we share is the \"~\" magic.\n\nMoreover, you are thinking of include.path as \"cat\":\n\n> So, because, e.g., the following works:\n> \n> > elsiehupp@Alpha:~$ cat ./**/github/.gitconfig\n> > [user]\n> > \temail = github@elsiehupp.com\n> \n> …one would expect, e.g., this gitconfig line to work, as well:\n> \n> > [include] path = ./**/github/.gitconfig\n\nThe expansion of the glob is done by the shell. But it is \"cat\" which is\nhappy to receive multiple files as input. But many other commands are\nnot, and include.path is not.\n\nNone of which is to say you're wrong to think of it this way. It's a\nperfectly valid mental model. It just happens not to be the mental model\nwe used when implementing it.\n\nI'm not entirely opposed to expanding globs in include.path values if\nsomebody wants to go to the trouble to implement it, but:\n\n  1. I'd be more convinced by a concrete use case. It sounds like\n     conditional includes were the real sticking point for yours. Maybe\n     somebody wants to do include.path on \".gitconfig.d/*\" or something?\n     I dunno.\n\n  2. It does involve breaking backwards compatibility slightly, in that\n     glob metacharacters do not currently need to be quoted. It's\n     somewhat unlikely somebody would have included them literally,\n     though.\n\n     But having include.dir or similar would extend the system without\n     breaking compatibility.\n\n> > elsiehupp@Alpha:~$ git config --get-all user.email\n> > github@elsiehupp.com\n> > gitlab@elsiehupp.com\n> > gnome@elsiehupp.com\n> > launchpad@elsiehupp.com\n> > github@elsiehupp.com\n> > xdg@elsiehupp.com\n> \n> I don’t know off the top of my head what happens when a single\n> variable is defined multiple times. I do get the following output,\n> though:\n\nIt depends on the variable. Most single-value options in Git are \"last\none wins\", but some are lists (e.g., remote.*.fetch). We also hold\nconfig values for other porcelain scripts whose semantics we may not\neven know ourselves. There are options to \"git config\" for specifying\nhow to handle these (e.g., --get-all).\n\n-Peff\n"},{"id":"465278","messageId":"90F9456A-6ABC-4555-8127-FF2DB0449EF1@elsiehupp.com","threadId":"58598","inReplyTo":"Y08SRgwIvDcsWF0Z@coredump.intra.peff.net","subject":"Re: Multiple --global config workspaces?","fromName":"Elsie Hupp","fromEmail":"git@elsiehupp.com","sentAt":"2022-10-20T02:29:42Z","receivedAt":"2022-10-20T02:30:06Z","isPatch":false,"sender":{"key":"git@elsiehupp.com","avatar":null},"body":"> The expansion of the glob is done by the shell. But it is \"cat\" which is\n> happy to receive multiple files as input. But many other commands are\n> not, and include.path is not.\n> \n> None of which is to say you're wrong to think of it this way. It's a\n> perfectly valid mental model. It just happens not to be the mental model\n> we used when implementing it.\n\nThe 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:\n\nhttps://git-scm.com/docs/git-config#Documentation/git-config.txt-codegitdircode\n\n> • 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.\n> • 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.\n\nLike 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.\n\nAdmittedly, 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.\n\n>  1. I'd be more convinced by a concrete use case. It sounds like\n>     conditional includes were the real sticking point for yours. Maybe\n>     somebody wants to do include.path on \".gitconfig.d/*\" or something?\n>     I dunno.\n\nBasically 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.\n\n>> I don’t know off the top of my head what happens when a single\n>> variable is defined multiple times. I do get the following output,\n>> though:\n> \n> It depends on the variable. Most single-value options in Git are \"last\n> one wins\", but some are lists (e.g., remote.*.fetch). We also hold\n> config values for other porcelain scripts whose semantics we may not\n> even know ourselves. There are options to \"git config\" for specifying\n> how to handle these (e.g., --get-all).\n\nI 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.\n\n> if somebody wants to go to the trouble to implement\n\nYeah this somebody is almost certainly not going to be me, considering my complete and utter unfamiliarity with the codebase, among other things. 😬\n\nAs 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…?\n\nBest,\nElsie\n\n"},{"id":"465279","messageId":"2A64CF44-0AE5-497D-85C7-F625B51EA28F@elsiehupp.com","threadId":"58598","inReplyTo":"90F9456A-6ABC-4555-8127-FF2DB0449EF1@elsiehupp.com","subject":"Re: Multiple --global config workspaces?","fromName":"Elsie Hupp","fromEmail":"git@elsiehupp.com","sentAt":"2022-10-20T02:39:45Z","receivedAt":"2022-10-20T02:39:51Z","isPatch":false,"sender":{"key":"git@elsiehupp.com","avatar":null},"body":"I might also mention recursive globbing à la bash globstar, as described here:\n\nhttps://unix.stackexchange.com/questions/49913/recursive-glob\n\n…but that’s getting quite a bit into the weeds (not to mention exceeding my personal knowledge of bash).\n\n> On Oct 19, 2022, at 10:29 PM, Elsie Hupp <git@elsiehupp.com> wrote:\n> \n>> The expansion of the glob is done by the shell. But it is \"cat\" which is\n>> happy to receive multiple files as input. But many other commands are\n>> not, and include.path is not.\n>> \n>> None of which is to say you're wrong to think of it this way. It's a\n>> perfectly valid mental model. It just happens not to be the mental model\n>> we used when implementing it.\n> \n> 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:\n> \n> https://git-scm.com/docs/git-config#Documentation/git-config.txt-codegitdircode\n> \n>> • 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.\n>> • 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.\n> \n> 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.\n> \n> 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.\n> \n>> 1. I'd be more convinced by a concrete use case. It sounds like\n>>    conditional includes were the real sticking point for yours. Maybe\n>>    somebody wants to do include.path on \".gitconfig.d/*\" or something?\n>>    I dunno.\n> \n> 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.\n> \n>>> I don’t know off the top of my head what happens when a single\n>>> variable is defined multiple times. I do get the following output,\n>>> though:\n>> \n>> It depends on the variable. Most single-value options in Git are \"last\n>> one wins\", but some are lists (e.g., remote.*.fetch). We also hold\n>> config values for other porcelain scripts whose semantics we may not\n>> even know ourselves. There are options to \"git config\" for specifying\n>> how to handle these (e.g., --get-all).\n> \n> 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.\n> \n>> if somebody wants to go to the trouble to implement\n> \n> Yeah this somebody is almost certainly not going to be me, considering my complete and utter unfamiliarity with the codebase, among other things. 😬\n> \n> 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…?\n> \n> Best,\n> Elsie\n> \n\n"}]}