Matthieu Moy venit, vidit, dixit 21.12.2009 17:26: > Jeff King <peff@xxxxxxxx> 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 ;-). 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html