git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: Junio C Hamano <gitster@pobox.com>,
	Miklos Vajna <vmiklos@frugalware.org>, Moe <moe@signalbeam.net>,
	git@vger.kernel.org
Subject: Re: [PATCH] Introduce the GIT_HOME environment variable
Date: Mon, 21 Dec 2009 10:59:02 -0500	[thread overview]
Message-ID: <20091221155902.GA22665@sigill.intra.peff.net> (raw)
In-Reply-To: <vpqhbrkd3o6.fsf@bauges.imag.fr>

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

  reply	other threads:[~2009-12-21 15:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-18 22:54 FEATURE REQUEST: Env override GIT_GLOBAL_CONFIG Moe
2009-12-19  1:32 ` [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable Miklos Vajna
2009-12-19  2:09   ` Shawn O. Pearce
2009-12-19  3:06     ` Moe
2009-12-19 14:25     ` Miklos Vajna
2009-12-19  3:24   ` Junio C Hamano
2009-12-19  4:44     ` Moe
2009-12-19  5:55       ` Junio C Hamano
2009-12-19  7:20         ` Moe
2009-12-19 10:54           ` Johannes Schindelin
2009-12-19 11:38             ` Moe
2009-12-19 14:45           ` Nanako Shiraishi
2009-12-19 15:30         ` [PATCH] Introduce the GIT_HOME " Miklos Vajna
2009-12-19 16:18           ` Michael J Gruber
2009-12-19 16:44             ` Miklos Vajna
2009-12-19 17:10           ` Matthieu Moy
2009-12-19 19:13             ` Junio C Hamano
2009-12-21 10:25               ` Matthieu Moy
2009-12-21 15:59                 ` Jeff King [this message]
2009-12-21 16:26                   ` Matthieu Moy
2009-12-21 16:54                     ` Michael J Gruber
2009-12-19 19:21           ` Junio C Hamano
2009-12-20  0:34             ` Miklos Vajna

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091221155902.GA22665@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=moe@signalbeam.net \
    --cc=vmiklos@frugalware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).