Re: [PATCH] Introduce the GIT_HOME environment variable

Junio C Hamano [off-list ref] writes:

Matthieu Moy [off-list ref] writes:

quoted

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/

On Mon, Dec 21, 2009 at 11:25:45AM +0100, Matthieu Moy wrote:

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".

Are we even close to having this sort of universal support for
~/.config? I also keep my dot-files in a git repository. I don't have a
single one in ~/.config[1], but I do have ~/.profile, ~/.vimrc,
~/.netrc, ~/.gitconfig, and others[2]. 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.

[1] I'll grant that is probably because I am a curmudgeon, and spend 99%
    of my computing time in xterm+bash+vim.

[2] Don't even get me started on ~/.mozilla/firefox/$RAND_HEX.default/user.js.

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?

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.


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. :)

-Peff