Jeff King [off-list ref] writes:
Are we even close to having this sort of universal support for
~/.config?
Definitely not universal as of now. Probably precisely because each
application thinks "I'll take care of $XDG_CONFIG_HOME after others
do" ;-).
Traditionally, the standard for Unix
has been for config files to be $HOME/.something. You can argue that
~/.config is a better standard, but I don't think git is failing to
use a standard; it is simply following a different one.
I've probably been unclear about this. I'm not arguing about moving
away from $HOME/.gitconfig as the default (IOW, we're in agreement
here ;-) ). It's there, and the migration path would be much more
painfull than the benefit.
What I'm saying is that _if_ we introduce a variable to point to an
alternate .gitconfig, then we should use something like
$XDG_CONFIG_HOME/git/config and not $GIT_HOME/.gitconfig
I don't have a strong opinion on whether we should introduce such
variable (it seems the only use-case is the one which started this
thread, and it is already solved without it, so ...).
But we do have such a variable: $HOME. The concept of $GIT_HOME was
proposed to provide a way to divert _just_ git to a different config
directory, something that would not be any easier with
$XDG_CONFIG_HOME.
Right, but I don't see any use-case for this.
The use-case which started this thread was to have several physical
users using the same Unix account, with the desire that each physical
user should be able to use his own editor setups. In this case, you
want your editor and your other applications to follow the schema.
Anyway, as far as the future of git goes, even if we did want to switch
to $XDG_CONFIG_HOME, we could not do so suddenly without breaking
everybody's current setup. Which would mean any implementation of it
would have to handle both the current and the new proposed locations.
You can obviously just read from both, but there are a lot of open
questions, like "which should take precedence?" and "what does git
config --global --edit do?". I am not opposed to hearing a clever
proposal that handles all such issues, but I am not going to think too
hard about it myself. :)
Right, the thing I had in mind was to use $XDG_CONFIG_HOME just like
$GIT_HOME (i.e. use it if it's set), but doing so would suddenly break
the setup of people having already set $XDG_CONFIG_HOME, and having a
$HOME/.gitconfig.
Well, then, I don't know, maybe my proposal wasn't as clever as I
thought ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Matthieu Moy venit, vidit, dixit 21.12.2009 17:26:
Jeff King [off-list ref] writes:
quoted
Are we even close to having this sort of universal support for
~/.config?
Definitely not universal as of now. Probably precisely because each
application thinks "I'll take care of $XDG_CONFIG_HOME after others
do" ;-).
quoted
Traditionally, the standard for Unix
has been for config files to be $HOME/.something. You can argue that
~/.config is a better standard, but I don't think git is failing to
use a standard; it is simply following a different one.
I've probably been unclear about this. I'm not arguing about moving
away from $HOME/.gitconfig as the default (IOW, we're in agreement
here ;-) ). It's there, and the migration path would be much more
painfull than the benefit.
What I'm saying is that _if_ we introduce a variable to point to an
alternate .gitconfig, then we should use something like
$XDG_CONFIG_HOME/git/config and not $GIT_HOME/.gitconfig
I don't have a strong opinion on whether we should introduce such
variable (it seems the only use-case is the one which started this
thread, and it is already solved without it, so ...).
quoted
But we do have such a variable: $HOME. The concept of $GIT_HOME was
proposed to provide a way to divert _just_ git to a different config
directory, something that would not be any easier with
$XDG_CONFIG_HOME.
Right, but I don't see any use-case for this.
The use-case which started this thread was to have several physical
users using the same Unix account, with the desire that each physical
user should be able to use his own editor setups. In this case, you
want your editor and your other applications to follow the schema.
quoted
Anyway, as far as the future of git goes, even if we did want to switch
to $XDG_CONFIG_HOME, we could not do so suddenly without breaking
everybody's current setup. Which would mean any implementation of it
would have to handle both the current and the new proposed locations.
You can obviously just read from both, but there are a lot of open
questions, like "which should take precedence?" and "what does git
config --global --edit do?". I am not opposed to hearing a clever
proposal that handles all such issues, but I am not going to think too
hard about it myself. :)
Right, the thing I had in mind was to use $XDG_CONFIG_HOME just like
$GIT_HOME (i.e. use it if it's set), but doing so would suddenly break
the setup of people having already set $XDG_CONFIG_HOME, and having a
$HOME/.gitconfig.
Well, then, I don't know, maybe my proposal wasn't as clever as I
thought ;-).
Well, I'd say the usual approach would be "use the first one found out
of $XYZ/config and $HOME/.gitconfig in this order", whether XYZ equals
$GIT_HOME or $XDG_CONFIG_HOME/git or what not. And that applies both to
reading as well writing the config. We should only merge config from
different types of sources (system/global/local), not from alternate
locations within the same type.
That way, nobody's setup gets broken, and having "git_custom_home()"
factorized out there is no real maintenance burden. I have no opinion
about the choice of XYZ.
Michael