git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Introduce the GIT_HOME environment variable

From
Jeff King <peff@peff.net>
Date
Dec 21, 2009, 15:59 UTC
Message-ID
<20091221155902.GA22665@sigill.intra.peff.net>
In-Reply-To
<vpqhbrkd3o6.fsf@bauges.imag.fr>
On Mon, Dec 21, 2009 at 11:25:45AM +0100, Matthieu Moy wrote:
Show 7 quoted lines
> 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.
Show 5 quoted lines
> 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
Previous: Matthieu MoyNext: Matthieu Moy
Message 19 of 23 in “FEATURE REQUEST: Env override GIT_GLOBAL_CONFIG”
  1. MoeDec 18, 2009
  2. Introduce the GIT_CONFIG_EXTRA environment variableMiklos Vajna, Dec 19, 2009
  3. Shawn O. PearceDec 19, 2009
  4. MoeDec 19, 2009
  5. Miklos VajnaDec 19, 2009
  6. Junio C HamanoDec 19, 2009
  7. MoeDec 19, 2009
  8. Junio C HamanoDec 19, 2009
  9. MoeDec 19, 2009
  10. Johannes SchindelinDec 19, 2009
  11. MoeDec 19, 2009
  12. Nanako ShiraishiDec 19, 2009
  13. Introduce the GIT_HOME environment variableMiklos Vajna, Dec 19, 2009
  14. Michael J GruberDec 19, 2009
  15. Introduce the GIT_HOME environment variableMiklos Vajna, Dec 19, 2009
  16. Matthieu MoyDec 19, 2009
  17. Junio C HamanoDec 19, 2009
  18. Matthieu MoyDec 21, 2009
  19. Jeff KingDec 21, 2009
  20. Matthieu MoyDec 21, 2009
  21. Michael J GruberDec 21, 2009
  22. Junio C HamanoDec 19, 2009
  23. Introduce the GIT_HOME environment variableMiklos Vajna, Dec 20, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.