Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?
On Sun, Dec 17, 2017 at 10:40 PM, Jeff King 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
Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?
Yaroslav Halchenko 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?
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?
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?
On Sat, Dec 16, 2017 at 2:01 PM, brian m. carlson wrote: > On Mon, Dec 11, 2017 at 05:05:01PM -0800, Junio C Hamano wrote: >> Jonathan Nieder 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?
On Mon, Dec 11, 2017 at 05:05:01PM -0800, Junio C Hamano wrote: > Jonathan Nieder 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 signature.asc Description: PGP signature
Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?
On Tue, Dec 12, 2017 at 11:36 AM, Junio C Hamano wrote: > Jacob Keller 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?
On Tue, Dec 12, 2017 at 6:13 AM, Yaroslav Halchenko wrote: > > On Mon, 11 Dec 2017, Junio C Hamano wrote: > >> Jonathan Nieder 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 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?
On Mon, 11 Dec 2017, Junio C Hamano wrote: > Jonathan Nieder 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?
On Mon, Dec 11, 2017 at 5:05 PM, Junio C Hamano wrote: > Jonathan Nieder 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?
Jonathan Nieder 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?
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?
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
