Junio C Hamano <gitster@xxxxxxxxx> writes: > Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > >> http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html >> >> It solves the same problem ("set on environment variable, and change >> my whole Git config"), but >> >> * It's a standard. It's really nice to be able to ... >> * It avoids hidden files. With $GIT_CONFIG, a user doing > > I think the above are actually three bullet points (i.e. you lack line > break and bullet before "It's really nice"). No, I don't. You can do | cd ~/.config | ls | | to see a user's configuration for many applications at a time, _because_ it's a standard, and because it's followed by several applications. > And the third bullet is more or less a small subset of the second > one, since you need "ls -a" without making them non-dot, The standard may not write black-on-white $XDG_CONFIG_HOME/subdir/filename _with filename being non-hidden_, but in practice, this is what's happening. > And I personally don't care very much about that second "It's really > nice to be able to" point. You may not care about consistancy between applications, but I do. Currently, to version-control my user's configuration, I have $HOME/etc containing my user's config files, and the actual config files are symlinks to it. If applications were agreeing on a directory where configuration files would be stored (is it is the case on systems like MS Windows, and I think Mac OS), I would just had done "cd this-config-directory; git init". With the proposed $GIT_HOME, I have a way to specify _Git_'s path to config files. Another application may propose $WHATEVER_ELSE_HOME, and yet another would say $HOME_YET_ANOTHER_ONE, and so on. There's a proposal to have a single environment variable for all this, why reject it? > As to the particular "standard" cited, I don't know how relevant it is to > us at this moment, or in this topic. Judging from the fact that it > doesn't even define the scope of the standard (e.g. what classes of > applications are expected to follow it, for what benefit do they follow > it, how are they expected to handle differences between their historical > practice and the new world order it introduces, etc. etc....), I suspect > it is a very early draft that will be heavily copyedited before final, > once professional standard writers start looking at it. I mostly agree on the critics, but do you have any better "standard" (actually, not necessarily an official standard, but "something that various applications can agree on") to propose? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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