Multiple --global config workspaces?

Multiple --global config workspaces?

[Elsie Hupp]

Hi Git Mailing List,

The 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. 

I structure my cloned repositories based on the remote host, e.g.:

~/Repositories/github/cloned-repository-name
~/Repositories/gitlab/other-cloned-repository-name

…and I sign my git commits for each remote host using an email address and signing key specific to that host.

I imagine many people have similar arrangements for the purpose of separating, say, work projects from personal projects.

Before I started using this workspace arrangement, I was able to do the following:

$ git config --global user.name "Elsie Hupp"
$ git config --global user.email "elsiehupp@example.com"

However, 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.

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.:

~/Repositories/github/.gitconfig
~/Repositories/gitlab/.gitconfig

…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.

(Obviously there are other ways this could be implemented, but this is the one that immediately came to mind.)

How 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?

Anyway, thank you for your time and attention.

Sincerely,
Elsie Hupp

Re: Multiple --global config workspaces?

[Junio C Hamano]

Elsie Hupp <git@elsiehupp.com> writes:

> I structure my cloned repositories based on the remote host, e.g.:
>
> ~/Repositories/github/cloned-repository-name
> ~/Repositories/gitlab/other-cloned-repository-name

The above is by definition not "global" (aka "per user").

"--global" is for things that are of your personal preference, not
"when I am working on this project, these settings apply" (which is
suitable for "per repository").

What you want is a way to say "when I am working on these projects,
these settings apply".

One way to do this would be to have

	[includeIf "gitdir:~/Repositories/github/"] path = $HOME/.githubconfig
	[includeIf "gitdir:~/Repositories/gitlab/"] path = $HOME/.gitlabconfig

in $HOME/.gitconfig and then write in these two extra files that are
conditionally included whatever settings you want to use for any and
all repositories that come from GitHub or GitLab.

$ git help config

and look for Conditional includes, perhaps?

Re: Multiple --global config workspaces?

[Jeff King]

On Mon, Oct 10, 2022 at 10:50:22PM -0700, Junio C Hamano wrote:

> One way to do this would be to have
> 
> 	[includeIf "gitdir:~/Repositories/github/"] path = $HOME/.githubconfig
> 	[includeIf "gitdir:~/Repositories/gitlab/"] path = $HOME/.gitlabconfig
> 
> in $HOME/.gitconfig and then write in these two extra files that are
> conditionally included whatever settings you want to use for any and
> all repositories that come from GitHub or GitLab.

I was about to write the same response. :) One small correction, though:
we don't expand $HOME in include paths. You can use "~", but easier
still is that non-absolute includes are relative to the including file.
Relative paths in includes are relative to the including file. So you
can just write ".githubconfig", etc, and we'll expect them adjacent to
$HOME/.gitconfig (or the xdg path if you use that, I guess).

-Peff

Re: Multiple --global config workspaces?

[Elsie Hupp]

Hi Junio, Reto, Jeff, Philip, et al,

Cool, thanks!

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

Even then, I don’t see includeIf in the first two web-based versions of the manpage for the DuckDuckGo query "man git-config":

https://linux.die.net/man/1/git-config
https://manpages.org/git-config

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):

https://man.archlinux.org/man/git-config.1

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):

https://git-scm.com/docs/git-config#_conditional_includes

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.)

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

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!)

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"

Or something like:

if "gitdir:gitlab/" email = "elsiehupp.gitlab@example.com”

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.

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?

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

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.

I guess for the time being what I’ll stick with is this:

[includeIf "gitdir:github/"] path = ./Repositories/github/.gitconfig
[includeIf "gitdir:gitlab/"] path = ./Repositories/gitlab/.gitconfig

Best,
Elsie Hupp


> On Oct 11, 2022, at 9:56 AM, Philip Oakley <philipoakley@iee.email> wrote:
> 
> On 11/10/2022 06:50, Junio C Hamano wrote:
>> Elsie Hupp <git@elsiehupp.com> writes:
>> 
>>> I structure my cloned repositories based on the remote host, e.g.:
>>> 
>>> ~/Repositories/github/cloned-repository-name
>>> ~/Repositories/gitlab/other-cloned-repository-name
>> The above is by definition not "global" (aka "per user").
>> 
>> "--global" is for things that are of your personal preference, not
>> "when I am working on this project, these settings apply" (which is
>> suitable for "per repository").
>> 
>> What you want is a way to say "when I am working on these projects,
>> these settings apply".
>> 
>> One way to do this would be to have
>> 
>> 	[includeIf "gitdir:~/Repositories/github/"] path = $HOME/.githubconfig
>> 	[includeIf "gitdir:~/Repositories/gitlab/"] path = $HOME/.gitlabconfig
>> 
>> in $HOME/.gitconfig and then write in these two extra files that are
>> conditionally included whatever settings you want to use for any and
>> all repositories that come from GitHub or GitLab.
>> 
>> $ git help config
>> 
>> and look for Conditional includes, perhaps?
>> 
>> 
> This use of "IncludeIf" for the Home/work case also came up in a recent
> Git for Windows discussion
> https://github.com/git-for-windows/git/discussions/4058
> 
> That discussion was about the trickiness of quoting when on the
> different Windows terminals/shells as the config string gets passed
> around (IIUC).
> 
> --
> Philip



> On Oct 11, 2022, at 1:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Elsie Hupp <git@elsiehupp.com> writes:
> 
>> I structure my cloned repositories based on the remote host, e.g.:
>> 
>> ~/Repositories/github/cloned-repository-name
>> ~/Repositories/gitlab/other-cloned-repository-name
> 
> The above is by definition not "global" (aka "per user").
> 
> "--global" is for things that are of your personal preference, not
> "when I am working on this project, these settings apply" (which is
> suitable for "per repository").
> 
> What you want is a way to say "when I am working on these projects,
> these settings apply".
> 
> One way to do this would be to have
> 
> 	[includeIf "gitdir:~/Repositories/github/"] path = $HOME/.githubconfig
> 	[includeIf "gitdir:~/Repositories/gitlab/"] path = $HOME/.gitlabconfig
> 
> in $HOME/.gitconfig and then write in these two extra files that are
> conditionally included whatever settings you want to use for any and
> all repositories that come from GitHub or GitLab.
> 
> $ git help config
> 
> and look for Conditional includes, perhaps?


> On Oct 11, 2022, at 1:51 AM, Reto <reto@labrat.space> wrote:
> 
> That already exists, git-config(1), look for "Conditional includes"
> That way you can do it per top level folder or whatever makes sense for
> you.
> 
> Examples:
> 
> ; include for all repositories inside /path/to/group
> [includeIf "gitdir:/path/to/group/"]
> 	   path = /path/to/foo.inc
> 
> ; include for all repositories inside $HOME/to/group
> [includeIf "gitdir:~/to/group/"]
> 	   path = /path/to/foo.inc


> On Oct 11, 2022, at 9:13 AM, Jeff King <peff@peff.net> wrote:
> 
> On Mon, Oct 10, 2022 at 10:50:22PM -0700, Junio C Hamano wrote:
> 
>> One way to do this would be to have
>> 
>> 	[includeIf "gitdir:~/Repositories/github/"] path = $HOME/.githubconfig
>> 	[includeIf "gitdir:~/Repositories/gitlab/"] path = $HOME/.gitlabconfig
>> 
>> in $HOME/.gitconfig and then write in these two extra files that are
>> conditionally included whatever settings you want to use for any and
>> all repositories that come from GitHub or GitLab.
> 
> I was about to write the same response. :) One small correction, though:
> we don't expand $HOME in include paths. You can use "~", but easier
> still is that non-absolute includes are relative to the including file.
> Relative paths in includes are relative to the including file. So you
> can just write ".githubconfig", etc, and we'll expect them adjacent to
> $HOME/.gitconfig (or the xdg path if you use that, I guess).
> 
> -Peff

Re: Multiple --global config workspaces?

[Elsie Hupp]

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:

https://github.com/progit/progit2/issues/1801

> On Oct 11, 2022, at 12:55 PM, Elsie Hupp <git@elsiehupp.com> wrote:
> 
> Hi Junio, Reto, Jeff, Philip, et al,
> 
> Cool, thanks!
> 
> 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
> 
> Even then, I don’t see includeIf in the first two web-based versions of the manpage for the DuckDuckGo query "man git-config":
> 
> https://linux.die.net/man/1/git-config
> https://manpages.org/git-config
> 
> 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):
> 
> https://man.archlinux.org/man/git-config.1
> 
> 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):
> 
> https://git-scm.com/docs/git-config#_conditional_includes
> 
> 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.)
> 
> 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
> 
> 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!)
> 
> 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"
> 
> Or something like:
> 
> if "gitdir:gitlab/" email = "elsiehupp.gitlab@example.com”
> 
> 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.
> 
> 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?
> 
> 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
> 
> 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.
> 
> I guess for the time being what I’ll stick with is this:
> 
> [includeIf "gitdir:github/"] path = ./Repositories/github/.gitconfig
> [includeIf "gitdir:gitlab/"] path = ./Repositories/gitlab/.gitconfig
> 
> Best,
> Elsie Hupp

Re: Multiple --global config workspaces?

[Jeff King]

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

Re: Multiple --global config workspaces?

[Matthias Aßhauer]

On Fri, 14 Oct 2022, Jeff King wrote:

> 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.

die.net is often quite high in the google results for me and from 
experience seems to be a common source when looking up man pages online.
Their git related man pages seem to be roughly from around Git 1.7.5. 
They do have a contact email at the bottom of their homepage. I'll try to 
poke them.

Best regards

Matthias

Re: Multiple --global config workspaces?

[Jeff King]

On Sat, Oct 15, 2022 at 12:56:38PM +0200, Matthias Aßhauer wrote:

> die.net is often quite high in the google results for me and from experience
> seems to be a common source when looking up man pages online.
> Their git related man pages seem to be roughly from around Git 1.7.5. They
> do have a contact email at the bottom of their homepage. I'll try to poke
> them.

Thanks for doing so. 1.7.5 is really quite old (2011!).

-Peff

Re: Multiple --global config workspaces?

[Elsie Hupp]

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@elsiehupp.com

…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@elsiehupp.com
> [user]
> 	email = gitlab@elsiehupp.com
> [user]
> 	email = gnome@elsiehupp.com
> [user]
> 	email = launchpad@elsiehupp.com
> [user]
> 	email = github@elsiehupp.com
> [user]
> 	email = xdg@elsiehupp.com

If I pipe the above into a new ~/.gitconfig, I can then do:

> elsiehupp@Alpha:~$ git config --get-all user.email
> github@elsiehupp.com
> gitlab@elsiehupp.com
> gnome@elsiehupp.com
> launchpad@elsiehupp.com
> github@elsiehupp.com
> xdg@elsiehupp.com

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@elsiehupp.com

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…)

Re: Multiple --global config workspaces?

[Jeff King]

On Tue, Oct 18, 2022 at 12:02:30AM -0400, Elsie Hupp wrote:

> > 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.

I'm not sure I buy this. We are not otherwise consistent with bash for
value expansion. For instance, we don't allow variable expansion like
$HOME. The only thing we share is the "~" magic.

Moreover, you are thinking of include.path as "cat":

> So, because, e.g., the following works:
> 
> > elsiehupp@Alpha:~$ cat ./**/github/.gitconfig
> > [user]
> > 	email = github@elsiehupp.com
> 
> …one would expect, e.g., this gitconfig line to work, as well:
> 
> > [include] path = ./**/github/.gitconfig

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.

I'm not entirely opposed to expanding globs in include.path values if
somebody wants to go to the trouble to implement it, but:

  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.

  2. It does involve breaking backwards compatibility slightly, in that
     glob metacharacters do not currently need to be quoted. It's
     somewhat unlikely somebody would have included them literally,
     though.

     But having include.dir or similar would extend the system without
     breaking compatibility.

> > elsiehupp@Alpha:~$ git config --get-all user.email
> > github@elsiehupp.com
> > gitlab@elsiehupp.com
> > gnome@elsiehupp.com
> > launchpad@elsiehupp.com
> > github@elsiehupp.com
> > xdg@elsiehupp.com
> 
> 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).

-Peff

Re: Multiple --global config workspaces?

[Elsie Hupp]

> 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

Re: Multiple --global config workspaces?

[Elsie Hupp]

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@elsiehupp.com> 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
> 

Re: Multiple --global config workspaces?

[Philip Oakley]

On 11/10/2022 06:50, Junio C Hamano wrote:
> Elsie Hupp <git@elsiehupp.com> writes:
>
>> I structure my cloned repositories based on the remote host, e.g.:
>>
>> ~/Repositories/github/cloned-repository-name
>> ~/Repositories/gitlab/other-cloned-repository-name
> The above is by definition not "global" (aka "per user").
>
> "--global" is for things that are of your personal preference, not
> "when I am working on this project, these settings apply" (which is
> suitable for "per repository").
>
> What you want is a way to say "when I am working on these projects,
> these settings apply".
>
> One way to do this would be to have
>
> 	[includeIf "gitdir:~/Repositories/github/"] path = $HOME/.githubconfig
> 	[includeIf "gitdir:~/Repositories/gitlab/"] path = $HOME/.gitlabconfig
>
> in $HOME/.gitconfig and then write in these two extra files that are
> conditionally included whatever settings you want to use for any and
> all repositories that come from GitHub or GitLab.
>
> $ git help config
>
> and look for Conditional includes, perhaps?
>
>
This use of "IncludeIf" for the Home/work case also came up in a recent
Git for Windows discussion
https://github.com/git-for-windows/git/discussions/4058

That discussion was about the trickiness of quoting when on the
different Windows terminals/shells as the config string gets passed
around (IIUC).

--
Philip

Re: Multiple --global config workspaces?

[Reto]

On Mon, Oct 10, 2022 at 11:06:32PM -0400, Elsie Hupp wrote:
> 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.:

> ~/Repositories/github/.gitconfig
> ~/Repositories/gitlab/.gitconfig

That already exists, git-config(1), look for "Conditional includes"
That way you can do it per top level folder or whatever makes sense for
you.

Examples:

; include for all repositories inside /path/to/group
[includeIf "gitdir:/path/to/group/"]
	   path = /path/to/foo.inc

; include for all repositories inside $HOME/to/group
[includeIf "gitdir:~/to/group/"]
	   path = /path/to/foo.inc