Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

[Yaroslav Halchenko]

Dear Git Gurus,

We [1] have got confused a bit about this recent addition of handling
$XDG_CONFIG_HOME/git/config -- is it --global or not? ;)

According to the man git-config (v 2.15.0 in debian)

       --global
           For writing options: write to global ~/.gitconfig file rather than
           the repository .git/config, write to $XDG_CONFIG_HOME/git/config
           file if this file exists and the ~/.gitconfig file doesn’t.

           For reading options: read only from global ~/.gitconfig and from
           $XDG_CONFIG_HOME/git/config rather than from all available files.

           See also the section called “FILES”.

suggesting that $XDG_CONFIG_HOME/git/config is a part of the "--global" config
space, which it is not, which is also later described in FILES:

       $(prefix)/etc/gitconfig
           System-wide configuration file.

       $XDG_CONFIG_HOME/git/config
           Second user-specific configuration file. If $XDG_CONFIG_HOME is not set or empty, $HOME/.config/git/config will be used. Any
           single-valued variable set in this file will be overwritten by whatever is in ~/.gitconfig. It is a good idea not to create this file if
           you sometimes use older versions of Git, as support for this file was added fairly recently.

       ~/.gitconfig
           User-specific configuration file. Also called "global" configuration file.

which

1. says that $XDG_CONFIG_HOME/git/config is the "Second user-specific ..."
   suggesting that it should be the one read AFTER the first user-specific...
   I guess that the first one is the ~/.gitconfig , but then why the first one
   overrides the settings of the second one ? ;)  (as described above in TFM and
   see below for an example)

2. why $XDG_CONFIG_HOME/git/config is not a part of the "global" configuration?

   I always assumed that "global" is ALL settings defined for a user,
   which are not specific to a repository.

   It is double-confusing since, as --global doc describes (and example
   below shows), git config --global --add modifies the
   $XDG_CONFIG_HOME/git/config if there is no ~/.gitconfig

   Actually the doc for --global for "reading" seems to be not correct,
   that the file is not consulted for --global (see below)

Example to show that TFM outlines precedence and --global correctly:

$> grep xdg .gitconfig .config/git/config                              
.gitconfig:    xdg-and-user = user
.config/git/config: xdg = xdg
.config/git/config: xdg-and-user = xdg
$> git config user.xdg ; git config user.xdg-and-user
xdg                          
user
$> git config --global user.xdg            # so outputs nothing
$> git config --global user.xdg-and-user
user

$> mv .gitconfig{,.aside}
$> git config --global --add user.new value 
$> cat .config/git/config 
[user]
 xdg = xdg
 xdg-and-user = xdg
 new = value


So, is that simply a bug and $XDG_CONFIG_HOME/git/config should be
consulted for --global reading and doc should be adjusted to
state that it is a part of "global" config in FILES description?
Or it shouldn't be --global (then writing should be fixed, and
documentation adjusted to exclude it from --global)
Or am I just confused? ;)

thanks in advance for the clarification!

[1]  https://github.com/datalad/datalad/pull/2019#issuecomment-350757960
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

[Jonathan Nieder]

Hi,

Yaroslav Halchenko wrote:

> Example to show that TFM outlines precedence and --global correctly:
>
> $> grep xdg .gitconfig .config/git/config
> .gitconfig:    xdg-and-user = user
> .config/git/config: xdg = xdg
> .config/git/config: xdg-and-user = xdg
> $> git config user.xdg ; git config user.xdg-and-user
> xdg
> user

I agree, this is confusing.

Reverse engineering from source, I find that git reads the following
files in sequence:

	system:
		/etc/gitconfig
	global:
		$XDG_CONFIG_HOME/git/config
		$HOME/.gitconfig
	repo:
		$GIT_DIR/config
	commandline:
		options passed with -c or GIT_CONFIG_PARAMETERS

These terms (system, global, repo, etc) are accessible in code as
current_config_scope().  I don't think there's any user-visible effect
to $XDG_CONFIG_HOME/git/config and $HOME/.gitconfig both being global
--- it would probably be a good cleanup to rename the scope for one of
them.

I think the documentation

	~/.gitconfig
		User-specific configuration file. Also called "global"
		configuration file.

should be clarified --- e.g. it could say

	$XDG_CONFIG_HOME/git/config
	~/.gitconfig
		User-specific configuration files. Because options in
		these files are not specific to any repository, thes
		are sometimes called global configuration files.

As for "git config --global", I think the best thing would be to split
it into two options: something like "git config --user" and "git
config --xdg-user".  That way, it is unambiguous which configuration
file the user intends to inspect or modify.  When a user calls "git
config --global" and both files exist, it could warn that the command
is ambiguous.

Thoughts?

Thanks,
Jonathan

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

[Yaroslav Halchenko]

On Mon, 11 Dec 2017, Jonathan Nieder wrote:
> > Example to show that TFM outlines precedence and --global correctly:

> > $> grep xdg .gitconfig .config/git/config
> > .gitconfig:    xdg-and-user = user
> > .config/git/config: xdg = xdg
> > .config/git/config: xdg-and-user = xdg
> > $> git config user.xdg ; git config user.xdg-and-user
> > xdg
> > user

> I agree, this is confusing.

> Reverse engineering from source, I find that git reads the following
> files in sequence:

> 	system:
> 		/etc/gitconfig
> 	global:
> 		$XDG_CONFIG_HOME/git/config
> 		$HOME/.gitconfig
> 	repo:
> 		$GIT_DIR/config
> 	commandline:
> 		options passed with -c or GIT_CONFIG_PARAMETERS

> These terms (system, global, repo, etc) are accessible in code as
> current_config_scope().  I don't think there's any user-visible effect
> to $XDG_CONFIG_HOME/git/config and $HOME/.gitconfig both being global
> --- it would probably be a good cleanup to rename the scope for one of
> them.

Well, we have got at least one user/contributor now who uses
$XDG_CONFIG_HOME/git/config in favor of ~/.gitconfig since it makes it
easier for modular user configuration.

> I think the documentation

> 	~/.gitconfig
> 		User-specific configuration file. Also called "global"
> 		configuration file.

> should be clarified --- e.g. it could say

> 	$XDG_CONFIG_HOME/git/config
> 	~/.gitconfig
> 		User-specific configuration files. Because options in
> 		these files are not specific to any repository, thes
> 		are sometimes called global configuration files.

> As for "git config --global", I think the best thing would be to split
> it into two options: something like "git config --user" and "git
> config --xdg-user".  That way, it is unambiguous which configuration
> file the user intends to inspect or modify.  When a user calls "git
> config --global" and both files exist, it could warn that the command
> is ambiguous.

why ambiguous?  as long as both are consistently called global, and the
overloading rules are clear for reading -- nothing ambigous.  The only
ambigous logic would be for writing.

> Thoughts?

Well -- my main functionality concern that ATM
$XDG_CONFIG_HOME/git/config is (as of 2.15.0) only --global for writing
but not for regular reading (as I demonstrated in the original email)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> I think the documentation
>
> 	~/.gitconfig
> 		User-specific configuration file. Also called "global"
> 		configuration file.
>
> should be clarified --- e.g. it could say
>
> 	$XDG_CONFIG_HOME/git/config
> 	~/.gitconfig
> 		User-specific configuration files. Because options in
> 		these files are not specific to any repository, thes
> 		are sometimes called global configuration files.

Yeah, I think that makes sense.

> As for "git config --global", I think the best thing would be to split
> it into two options: something like "git config --user" and "git
> config --xdg-user".  That way, it is unambiguous which configuration
> file the user intends to inspect or modify.  When a user calls "git
> config --global" and both files exist, it could warn that the command
> is ambiguous.
>
> Thoughts?

I actually thought that the plan was "you either have this, or the
other one, never both at the same time" (and I think those who
pushed the XDG thing in to the system made us favor it over the
traditional one).  So as long as --global updates the one that
exists, and updates XDG one when both or neither do, I think we
should be OK.  And from that viewpoint, we definitely do not want
two kinds of --global to pretend as if we support use of both at the
same time.

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

[Jacob Keller]

On Mon, Dec 11, 2017 at 5:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> I think the documentation
>>
>>       ~/.gitconfig
>>               User-specific configuration file. Also called "global"
>>               configuration file.
>>
>> should be clarified --- e.g. it could say
>>
>>       $XDG_CONFIG_HOME/git/config
>>       ~/.gitconfig
>>               User-specific configuration files. Because options in
>>               these files are not specific to any repository, thes
>>               are sometimes called global configuration files.
>
> Yeah, I think that makes sense.
>
>> As for "git config --global", I think the best thing would be to split
>> it into two options: something like "git config --user" and "git
>> config --xdg-user".  That way, it is unambiguous which configuration
>> file the user intends to inspect or modify.  When a user calls "git
>> config --global" and both files exist, it could warn that the command
>> is ambiguous.
>>
>> Thoughts?
>
> I actually thought that the plan was "you either have this, or the
> other one, never both at the same time" (and I think those who
> pushed the XDG thing in to the system made us favor it over the
> traditional one).  So as long as --global updates the one that
> exists, and updates XDG one when both or neither do, I think we
> should be OK.  And from that viewpoint, we definitely do not want
> two kinds of --global to pretend as if we support use of both at the
> same time.
>

It appears that we actually prefer ~/.gitconfig rather than XDG_CONFIG_HOME..

And at least based on current cursory testing on the command line, we
do both read and write to the proper location, assuming that
~/.gitconfig is preferred over $XDG_CONFIG_HOME.

Thanks,
Jake

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

[Yaroslav Halchenko]

On Mon, 11 Dec 2017, Junio C Hamano wrote:

> Jonathan Nieder <jrnieder@gmail.com> writes:

> > I think the documentation

> > 	~/.gitconfig
> > 		User-specific configuration file. Also called "global"
> > 		configuration file.

> > should be clarified --- e.g. it could say

> > 	$XDG_CONFIG_HOME/git/config
> > 	~/.gitconfig
> > 		User-specific configuration files. Because options in
> > 		these files are not specific to any repository, thes
> > 		are sometimes called global configuration files.

> Yeah, I think that makes sense.

> > As for "git config --global", I think the best thing would be to split
> > it into two options: something like "git config --user" and "git
> > config --xdg-user".  That way, it is unambiguous which configuration
> > file the user intends to inspect or modify.  When a user calls "git
> > config --global" and both files exist, it could warn that the command
> > is ambiguous.

> > Thoughts?

> I actually thought that the plan was "you either have this, or the
> other one, never both at the same time" (and I think those who
> pushed the XDG thing in to the system made us favor it over the
> traditional one).  So as long as --global updates the one that
> exists, and updates XDG one when both or neither do, I think we
> should be OK.  And from that viewpoint, we definitely do not want
> two kinds of --global to pretend as if we support use of both at the
> same time.

note that atm $XDG_CONFIG_HOME/git/config is read as --global iff
~/.gitconfig is absent and read always without --global.  So it is
flipping between "global" and "some kind of non-global but user-specific
configuration file" (so sounds like  a global to me ;) )

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

[Junio C Hamano]

Jacob Keller <jacob.keller@gmail.com> writes:

>> I actually thought that the plan was "you either have this, or the
>> other one, never both at the same time" (and I think those who
>> pushed the XDG thing in to the system made us favor it over the
>> traditional one).  So as long as --global updates the one that
>> exists, and updates XDG one when both or neither do, I think we
>> should be OK.  And from that viewpoint, we definitely do not want
>> two kinds of --global to pretend as if we support use of both at the
>> same time.
>
> It appears that we actually prefer ~/.gitconfig rather than XDG_CONFIG_HOME..
>
> And at least based on current cursory testing on the command line, we
> do both read and write to the proper location, assuming that
> ~/.gitconfig is preferred over $XDG_CONFIG_HOME.

OK, so I misremembered the details but it seems that the behaviour
is consistent and there is no ambiguity?  

Am I reading you correctly?

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

[Jacob Keller]

On Tue, Dec 12, 2017 at 6:13 AM, Yaroslav Halchenko <yoh@onerussian.com> wrote:
>
> On Mon, 11 Dec 2017, Junio C Hamano wrote:
>
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> > I think the documentation
>
>> >     ~/.gitconfig
>> >             User-specific configuration file. Also called "global"
>> >             configuration file.
>
>> > should be clarified --- e.g. it could say
>
>> >     $XDG_CONFIG_HOME/git/config
>> >     ~/.gitconfig
>> >             User-specific configuration files. Because options in
>> >             these files are not specific to any repository, thes
>> >             are sometimes called global configuration files.
>
>> Yeah, I think that makes sense.
>
>> > As for "git config --global", I think the best thing would be to split
>> > it into two options: something like "git config --user" and "git
>> > config --xdg-user".  That way, it is unambiguous which configuration
>> > file the user intends to inspect or modify.  When a user calls "git
>> > config --global" and both files exist, it could warn that the command
>> > is ambiguous.
>
>> > Thoughts?
>
>> I actually thought that the plan was "you either have this, or the
>> other one, never both at the same time" (and I think those who
>> pushed the XDG thing in to the system made us favor it over the
>> traditional one).  So as long as --global updates the one that
>> exists, and updates XDG one when both or neither do, I think we
>> should be OK.  And from that viewpoint, we definitely do not want
>> two kinds of --global to pretend as if we support use of both at the
>> same time.
>
> note that atm $XDG_CONFIG_HOME/git/config is read as --global iff
> ~/.gitconfig is absent and read always without --global.  So it is
> flipping between "global" and "some kind of non-global but user-specific
> configuration file" (so sounds like  a global to me ;) )
>
> --
> Yaroslav O. Halchenko
> Center for Open Neuroscience     http://centerforopenneuroscience.org
> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
> WWW:   http://www.linkedin.com/in/yarik

I didn't see it read, if ~/.gitconfig exists, it appears to never be
read on my system..

Thanks,
Jake

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

[Jacob Keller]

On Tue, Dec 12, 2017 at 11:36 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jacob Keller <jacob.keller@gmail.com> writes:
>
>>> I actually thought that the plan was "you either have this, or the
>>> other one, never both at the same time" (and I think those who
>>> pushed the XDG thing in to the system made us favor it over the
>>> traditional one).  So as long as --global updates the one that
>>> exists, and updates XDG one when both or neither do, I think we
>>> should be OK.  And from that viewpoint, we definitely do not want
>>> two kinds of --global to pretend as if we support use of both at the
>>> same time.
>>
>> It appears that we actually prefer ~/.gitconfig rather than XDG_CONFIG_HOME..
>>
>> And at least based on current cursory testing on the command line, we
>> do both read and write to the proper location, assuming that
>> ~/.gitconfig is preferred over $XDG_CONFIG_HOME.
>
> OK, so I misremembered the details but it seems that the behaviour
> is consistent and there is no ambiguity?
>
> Am I reading you correctly?

As far as I could tell based on local testing. I could be wrong, and
haven't yet cooked up a test case for it yet.

Thanks,
Jake

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

On Mon, Dec 11, 2017 at 05:05:01PM -0800, Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
> > As for "git config --global", I think the best thing would be to split
> > it into two options: something like "git config --user" and "git
> > config --xdg-user".  That way, it is unambiguous which configuration
> > file the user intends to inspect or modify.  When a user calls "git
> > config --global" and both files exist, it could warn that the command
> > is ambiguous.
> >
> > Thoughts?
> 
> I actually thought that the plan was "you either have this, or the
> other one, never both at the same time" (and I think those who
> pushed the XDG thing in to the system made us favor it over the
> traditional one).  So as long as --global updates the one that
> exists, and updates XDG one when both or neither do, I think we
> should be OK.  And from that viewpoint, we definitely do not want
> two kinds of --global to pretend as if we support use of both at the
> same time.

Sorry for coming late to the discussion, but I actually use both.

~/.gitconfig is checked into my Git repo for my home directory and
contains settings I preserve across all systems, and the XDG dir is not
checked in and contains per-system settings (currently just
commit.gpgsign).  On my main systems I have a key and sign commits; if
it's just some server I log into, I don't.

Now, I don't use git config to set options, so I'm happy as long as git
config can read both, which it does.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 867 bytes --]

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

[Jacob Keller]

On Sat, Dec 16, 2017 at 2:01 PM, brian m. carlson
<sandals@crustytoothpaste.net> wrote:
> On Mon, Dec 11, 2017 at 05:05:01PM -0800, Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>> > As for "git config --global", I think the best thing would be to split
>> > it into two options: something like "git config --user" and "git
>> > config --xdg-user".  That way, it is unambiguous which configuration
>> > file the user intends to inspect or modify.  When a user calls "git
>> > config --global" and both files exist, it could warn that the command
>> > is ambiguous.
>> >
>> > Thoughts?
>>
>> I actually thought that the plan was "you either have this, or the
>> other one, never both at the same time" (and I think those who
>> pushed the XDG thing in to the system made us favor it over the
>> traditional one).  So as long as --global updates the one that
>> exists, and updates XDG one when both or neither do, I think we
>> should be OK.  And from that viewpoint, we definitely do not want
>> two kinds of --global to pretend as if we support use of both at the
>> same time.
>
> Sorry for coming late to the discussion, but I actually use both.
>
> ~/.gitconfig is checked into my Git repo for my home directory and
> contains settings I preserve across all systems, and the XDG dir is not
> checked in and contains per-system settings (currently just
> commit.gpgsign).  On my main systems I have a key and sign commits; if
> it's just some server I log into, I don't.
>
> Now, I don't use git config to set options, so I'm happy as long as git
> config can read both, which it does.
> --
> brian m. carlson / brian with sandals: Houston, Texas, US
> https://www.crustytoothpaste.net/~bmc | My opinion only
> OpenPGP: https://keybase.io/bk2204


Ok, so my patch documentation is wrong. Perhaps we could further
clarify in the documentation how it works, but I'm not really sure
what the best approach is.

I do find it a bit weird that --global writes to one of either file,
and doesn't read from both. I'd rather have --global "only" be
.gitconfig, and instead add a new option for handling XDG file, and
then have it such that it reads them in system -> xdg ->
home/.gitconfig -> local, which allows for local .gitconfig to
override XDG config, but logically treat them just like we do any
other files.

Thanks,
Jake

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

[Jeff King]

On Sun, Dec 17, 2017 at 08:03:41PM -0800, Jacob Keller wrote:

> I do find it a bit weird that --global writes to one of either file,
> and doesn't read from both. I'd rather have --global "only" be
> .gitconfig, and instead add a new option for handling XDG file, and
> then have it such that it reads them in system -> xdg ->
> home/.gitconfig -> local, which allows for local .gitconfig to
> override XDG config, but logically treat them just like we do any
> other files.

I find it weird, too, but I'm not sure that's the right direction. It
means that users have to start caring about using "--xdg" instead of
"--global" if that's what they want to write to. The original idea was
that the transition to xdg should be fairly seamless, and that --global
would be an abstraction over both.

To complete that abstraction it seems like reading via "--global" should
read from both (in the same precedence order that normal config lookup
uses). If you only use one, there wouldn't be any change in behavior.
And if you use both, then the behavior makes sense as a subset of the
normal config lookup. I.e., it could even be explained as:

  If you give no "source", normal config lookup is similar to checking
  "--system", then "--global", then "--local".

The only person who might be affected is somebody who carries both files
_and_ really wanted "--global" to read from one specific file (though I
have no idea from which without looking at the source, and from reading
this thread it seems I am not the only one who would be confused). So
I'd be OK calling that an unintended and unsupported behavior, and the
right thing all along should have been to use "--file=" if you really
want to avoid "--global" automagic.

-Peff

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

[Yaroslav Halchenko]

On Mon, 18 Dec 2017, Jeff King wrote:

> To complete that abstraction it seems like reading via "--global" should
> read from both (in the same precedence order that normal config lookup
> uses).

FWIW +1 from me on that ;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

[Junio C Hamano]

Yaroslav Halchenko <yoh@onerussian.com> writes:

> On Mon, 18 Dec 2017, Jeff King wrote:
>
>> To complete that abstraction it seems like reading via "--global" should
>> read from both (in the same precedence order that normal config lookup
>> uses).
>
> FWIW +1 from me on that ;)

FWIW I do not have problem with that endgame.

I wonder if anybody wants to get their hands dirty.  It should be a
quite straight-forward to split a helper (or three) out of the
do_git_config_sequence() helper, but the interface from cmd_config()
to call into config.c to read a specific "class" of config file is
the same codepath as a single file, so a major part of this work
will be to design how to extend the interface to do the limited
"sequence" thing.

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

[Jacob Keller]

On Sun, Dec 17, 2017 at 10:40 PM, Jeff King <peff@peff.net> wrote:
> On Sun, Dec 17, 2017 at 08:03:41PM -0800, Jacob Keller wrote:
>
>> I do find it a bit weird that --global writes to one of either file,
>> and doesn't read from both. I'd rather have --global "only" be
>> .gitconfig, and instead add a new option for handling XDG file, and
>> then have it such that it reads them in system -> xdg ->
>> home/.gitconfig -> local, which allows for local .gitconfig to
>> override XDG config, but logically treat them just like we do any
>> other files.
>
> I find it weird, too, but I'm not sure that's the right direction. It
> means that users have to start caring about using "--xdg" instead of
> "--global" if that's what they want to write to. The original idea was
> that the transition to xdg should be fairly seamless, and that --global
> would be an abstraction over both.
>
> To complete that abstraction it seems like reading via "--global" should
> read from both (in the same precedence order that normal config lookup
> uses). If you only use one, there wouldn't be any change in behavior.
> And if you use both, then the behavior makes sense as a subset of the
> normal config lookup. I.e., it could even be explained as:
>
>   If you give no "source", normal config lookup is similar to checking
>   "--system", then "--global", then "--local".
>
> The only person who might be affected is somebody who carries both files
> _and_ really wanted "--global" to read from one specific file (though I
> have no idea from which without looking at the source, and from reading
> this thread it seems I am not the only one who would be confused). So
> I'd be OK calling that an unintended and unsupported behavior, and the
> right thing all along should have been to use "--file=" if you really
> want to avoid "--global" automagic.
>
> -Peff

I think this end game is fine with me too, it's definitely better than
what we have now.

Thanks,
Jake