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

Re: [PATCH] Introduce the GIT_HOME environment variable

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Dec 21, 2009, 16:54 UTC
Message-ID
<4B2FA82B.3080305@drmicha.warpmail.net>
In-Reply-To
<vpqskb49tuq.fsf@bauges.imag.fr>
Matthieu Moy venit, vidit, dixit 21.12.2009 17:26:
Show 56 quoted lines
> Jeff King <peff@peff.net> 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
Previous: Matthieu MoyNext: Junio C Hamano
Message 21 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.