Re: [RFC] Possibility to choose ~/.config/git/config instead of ~/.gitconfig

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

Junio C Hamano <gitster@pobox.com> writes:

>> Besides, with my distro package maintainer hat on, I can tell you that
>> switching the config file to ~/.config/git and not reading
>> ~/.gitconfig would be a complete nonstarter.
>
> Absolutely.  So don't choose to deliberately introduce backward
> incompatibliity.  Problem solved.

It doesn't have to be backward incompatible. The proposal is to _allow_
users to have a ~/.config/git/config file, not to _force_ them to have
one.

If Git reads both files, then ~/.gitconfig lovers can continue with it,
and are not affected.

> Why is it bad to keep using ~/.gitconfig in the first place?  The UNIX
> convention to exclude names that begin with dot is not working for you?

The "It's a convention" argument doesn't work here. XDG is also a rather
widely used convention these days, so "why not follow the convention"
can be used both in favor of ~/.gitconfig or ~/.config/git/config.

~/.gitconfig alone would not be a huge problem, although personnally
hate it already. I like to version my handwritten configuration files,
but I don't want my $HOME to be a git repository. I already have a
~/etc/ directory with my configuration files in it, and ~/.gitconfig is
basically a symbolic link. I wouldn't have to re-structure my $HOME if I
had a structured and standard configuration directory like ~/.config.

Now, the real issue is that we're starting to have several user-wide
config files (core.excludesfile, core.attributesfile, maybe one day
we'll want others like user-wide hooks?), and having multiple
~/.git<something> really feels wrong. Just like we have /etc/<file> for
applications that have only one configuration file, and /etc/<directory>
for ones who need more, it seems sensible to have a configuration
directory for a user, not just a set of configuration files in $HOME.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/