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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 11, 2017 at 05:05:01PM -0800, Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@xxxxxxxxx> 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: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux