{"thread":{"id":"21986","subject":"FEATURE REQUEST: Env override GIT_GLOBAL_CONFIG","startedAt":"2009-12-18T22:54:32Z","lastAt":"2009-12-21T16:54:03Z","messageCount":23,"participants":["Moe","Miklos Vajna","Shawn O. Pearce","Junio C Hamano","Johannes Schindelin","Nanako Shiraishi","Michael J Gruber","Matthieu Moy","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"130106","messageId":"4B2C0828.4010505@signalbeam.net","threadId":"21986","inReplyTo":null,"subject":"FEATURE REQUEST: Env override GIT_GLOBAL_CONFIG","fromName":"Moe","fromEmail":"moe@signalbeam.net","sentAt":"2009-12-18T22:54:32Z","receivedAt":"2009-12-18T22:54:32Z","isPatch":false,"sender":{"key":"moe@signalbeam.net","avatar":null},"body":"Hello list,\n\nI'm looking for a way to read a custom config file in\naddition to .git/config.\n\nAn env var along the lines of GIT_GLOBAL_CONFIG (and perhaps\nGIT_SYSTEM_CONFIG) to override the default locations of\n~/.gitconfig or $prefix/etc/gitconfig would be most\nwelcome here.\n\n$GIT_CONFIG doesn't work for this purpose because when set\ngit will *only* read the referenced file and ignore the\nrepository settings.\n\n$GIT_CONFIG_LOCAL wouldn't do either and has been\nremoved from git anyways.\n\n\nUse-Case:\nMultiple users sharing one unix account. Trying to inject the respective\ngit identity and other preferences without overwriting\nthe actual .gitconfig-file - because that doesn't work when multiple\nusers are logged in concurrently to the same unix-account.\n\n\nKind regards,\nMoe\n"},{"id":"130113","messageId":"20091219013246.GD25474@genesis.frugalware.org","threadId":"21986","inReplyTo":"4B2C0828.4010505@signalbeam.net","subject":"[PATCH] Introduce the GIT_CONFIG_EXTRA environment variable","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2009-12-19T01:32:46Z","receivedAt":"2009-12-19T01:32:46Z","isPatch":true,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"This is like GIT_CONFIG but it is not read instead of .git/config, but\nin addtition to it.\n\nSigned-off-by: Miklos Vajna <vmiklos@frugalware.org>\n---\n\nOn Fri, Dec 18, 2009 at 11:54:32PM +0100, Moe <moe@signalbeam.net> wrote:\n> $GIT_CONFIG doesn't work for this purpose because when set\n> git will *only* read the referenced file and ignore the\n> repository settings.\n\nWhat about this?\n\n Documentation/git-config.txt |    3 +++\n builtin-config.c             |    7 ++++++-\n config.c                     |    9 ++++++++-\n t/t1300-repo-config.sh       |   16 ++++++++++++++++\n 4 files changed, 33 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-config.txt b/Documentation/git-config.txt\nindex f68b198..668db3f 100644\n--- a/Documentation/git-config.txt\n+++ b/Documentation/git-config.txt\n@@ -211,6 +211,9 @@ GIT_CONFIG::\n \tUsing the \"--global\" option forces this to ~/.gitconfig. Using the\n \t\"--system\" option forces this to $(prefix)/etc/gitconfig.\n \n+GIT_CONFIG_EXTRA::\n+\tTake the configuration from the given file in addition to .git/config.\n+\n See also <<FILES>>.\n \n \ndiff --git a/builtin-config.c b/builtin-config.c\nindex a2d656e..4a702f6 100644\n--- a/builtin-config.c\n+++ b/builtin-config.c\n@@ -142,7 +142,7 @@ static int get_value(const char *key_, const char *regex_)\n \tint ret = -1;\n \tchar *tl;\n \tchar *global = NULL, *repo_config = NULL;\n-\tconst char *system_wide = NULL, *local;\n+\tconst char *system_wide = NULL, *local, *extra = NULL;\n \n \tlocal = config_exclusive_filename;\n \tif (!local) {\n@@ -152,6 +152,7 @@ static int get_value(const char *key_, const char *regex_)\n \t\t\tglobal = xstrdup(mkpath(\"%s/.gitconfig\", home));\n \t\tif (git_config_system())\n \t\t\tsystem_wide = git_etc_gitconfig();\n+\t\textra = getenv(\"GIT_CONFIG_EXTRA\");\n \t}\n \n \tkey = xstrdup(key_);\n@@ -185,11 +186,15 @@ static int get_value(const char *key_, const char *regex_)\n \t\tgit_config_from_file(show_config, system_wide, NULL);\n \tif (do_all && global)\n \t\tgit_config_from_file(show_config, global, NULL);\n+\tif (do_all && extra)\n+\t\tgit_config_from_file(show_config, extra, NULL);\n \tgit_config_from_file(show_config, local, NULL);\n \tif (!do_all && !seen && global)\n \t\tgit_config_from_file(show_config, global, NULL);\n \tif (!do_all && !seen && system_wide)\n \t\tgit_config_from_file(show_config, system_wide, NULL);\n+\tif (!do_all && !seen && extra)\n+\t\tgit_config_from_file(show_config, extra, NULL);\n \n \tfree(key);\n \tif (regexp) {\ndiff --git a/config.c b/config.c\nindex 37385ce..cf816ed 100644\n--- a/config.c\n+++ b/config.c\n@@ -700,7 +700,7 @@ int git_config(config_fn_t fn, void *data)\n {\n \tint ret = 0, found = 0;\n \tchar *repo_config = NULL;\n-\tconst char *home = NULL;\n+\tconst char *home = NULL, *extra = NULL;\n \n \t/* Setting $GIT_CONFIG makes git read _only_ the given config file. */\n \tif (config_exclusive_filename)\n@@ -727,6 +727,13 @@ int git_config(config_fn_t fn, void *data)\n \t\tfound += 1;\n \t}\n \tfree(repo_config);\n+\n+\textra = getenv(\"GIT_CONFIG_EXTRA\");\n+\tif (extra && !access(extra, R_OK)) {\n+\t\tret += git_config_from_file(fn, extra, data);\n+\t\tfound += 1;\n+\t}\n+\n \tif (found == 0)\n \t\treturn -1;\n \treturn ret;\ndiff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh\nindex 83b7294..ed7fcb6 100755\n--- a/t/t1300-repo-config.sh\n+++ b/t/t1300-repo-config.sh\n@@ -398,6 +398,22 @@ test_expect_success 'alternative GIT_CONFIG' 'cmp output expect'\n test_expect_success 'alternative GIT_CONFIG (--file)' \\\n \t'git config --file other-config -l > output && cmp output expect'\n \n+cat > extra-config <<EOF\n+[extra]\n+\tconfig = value\n+EOF\n+\n+cat > expect << EOF\n+c\n+value\n+EOF\n+\n+test_expect_success 'additional GIT_CONFIG_EXTRA' '\n+\tGIT_CONFIG_EXTRA=extra-config git config a.b > output &&\n+\tGIT_CONFIG_EXTRA=extra-config git config extra.config >> output &&\n+\tcmp output expect\n+'\n+\n GIT_CONFIG=other-config git config anwohner.park ausweis\n \n cat > expect << EOF\n-- \n1.6.5.2\n"},{"id":"130114","messageId":"20091219020947.GB10687@spearce.org","threadId":"21986","inReplyTo":"20091219013246.GD25474@genesis.frugalware.org","subject":"Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-12-19T02:09:47Z","receivedAt":"2009-12-19T02:09:47Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Miklos Vajna <vmiklos@frugalware.org> wrote:\n> This is like GIT_CONFIG but it is not read instead of .git/config, but\n> in addtition to it.\n\nWhat file does `git config --add` modify?  Should we be able to\nmodify the GIT_CONFIG_EXTRA file?\n\nWhat order is GIT_CONFIG_EXTRA applied in relative to other files\nthat git config would also have read?\n\n-- \nShawn.\n"},{"id":"130116","messageId":"4B2C4320.6060007@signalbeam.net","threadId":"21986","inReplyTo":"20091219020947.GB10687@spearce.org","subject":"Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable","fromName":"Moe","fromEmail":"moe@signalbeam.net","sentAt":"2009-12-19T03:06:08Z","receivedAt":"2009-12-19T03:06:08Z","isPatch":true,"sender":{"key":"moe@signalbeam.net","avatar":null},"body":"Shawn O. Pearce wrote:\n> Miklos Vajna <vmiklos@frugalware.org> wrote:\n>> This is like GIT_CONFIG but it is not read instead of .git/config, but\n>> in addtition to it.\n> \n> What file does `git config --add` modify?  Should we be able to\n> modify the GIT_CONFIG_EXTRA file?\n\n>From my use-case corner: Yes, this would basically be used\nto divert ~/.gitconfig and should behave in all the same ways.\n\n> What order is GIT_CONFIG_EXTRA applied in relative to other files\n> that git config would also have read?\n\nThis is up to Miklos to answer but again from my use-case angle it would\nmake the most sense to read the usual config files first\nand GIT_CONFIG_EXTRA last - that way the user config gets the\nlast word in terms of overriding global and repository defaults.\n\nAnd btw, thanks for the fast action Miklos!\n\n\nKind regards,\nMoe\n"},{"id":"130117","messageId":"7vhbrnodd9.fsf@alter.siamese.dyndns.org","threadId":"21986","inReplyTo":"20091219013246.GD25474@genesis.frugalware.org","subject":"Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-19T03:24:02Z","receivedAt":"2009-12-19T03:24:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miklos Vajna <vmiklos@frugalware.org> writes:\n\n> This is like GIT_CONFIG but it is not read instead of .git/config, but\n> in addtition to it.\n>\n> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>\n> ---\n>\n> On Fri, Dec 18, 2009 at 11:54:32PM +0100, Moe <moe@signalbeam.net> wrote:\n>> $GIT_CONFIG doesn't work for this purpose because when set\n>> git will *only* read the referenced file and ignore the\n>> repository settings.\n>\n> What about this?\n\n\nThe patch text itself may be fine, in the sense that it makes \"we read\nfrom three\" to \"we now read from four\", but I am not impressed.\n\nI find the original use case highly moronic.\n\nFor people to be sharing an account, hence $HOME, there must be a reason.\nThey want to (rather, the administrator wants them to) use a common shared\nset of settings, so $HOME/.gitconfig should be shared among them, just\nlike $HOME/.emacs and $HOME/.login are, unless there is some strong reason\nto treat .gitconfig any differently from all the other $HOME/.whatever\nfiles.  But I don't think there wasn't any argument to defend that.\n\nThat makes the patch doubly suspect and throws it into \"because we can\",\nnot \"because we should\".\n\nWouldn't it be just a matter of giving different HOME after they log-in?\n\nAfter all, Moe will be giving _some_ way to his users set different value\nto GIT_CONFIG_EXTRA depending on who they really are, and that same\nmechanism should be usable to set different HOME to them, no?\n\nAs $HOME/.gitconfig is relative to the value of that environment variable,\nI don't see a reason for us to fall into this \"three is not enough, but\nwhen we add another, we are fine\" attitude, which makes me suspect that\nthere is something fundamentally wrong there.\n"},{"id":"130119","messageId":"4B2C5A1A.8000201@signalbeam.net","threadId":"21986","inReplyTo":"7vhbrnodd9.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable","fromName":"Moe","fromEmail":"moe@signalbeam.net","sentAt":"2009-12-19T04:44:10Z","receivedAt":"2009-12-19T04:44:10Z","isPatch":true,"sender":{"key":"moe@signalbeam.net","avatar":null},"body":"Junio C Hamano wrote:\n> Miklos Vajna <vmiklos@frugalware.org> writes:\n> \n>> This is like GIT_CONFIG but it is not read instead of .git/config, but\n>> in addtition to it.\n>>\n>> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>\n>> ---\n>>\n>> On Fri, Dec 18, 2009 at 11:54:32PM +0100, Moe <moe@signalbeam.net> wrote:\n>>> $GIT_CONFIG doesn't work for this purpose because when set\n>>> git will *only* read the referenced file and ignore the\n>>> repository settings.\n>> What about this?\n> \n> \n> The patch text itself may be fine, in the sense that it makes \"we read\n> from three\" to \"we now read from four\", but I am not impressed.\n> \n> I find the original use case highly moronic.\n>\n> For people to be sharing an account, hence $HOME, there must be a reason.\n> They want to (rather, the administrator wants them to) use a common shared\n> set of settings, so $HOME/.gitconfig should be shared among them, just\n> like $HOME/.emacs and $HOME/.login are, unless there is some strong reason\n> to treat .gitconfig any differently from all the other $HOME/.whatever\n> files.  But I don't think there wasn't any argument to defend that.\n\nI'm not arguing to treat .gitconfig differently from other\ndot-files, but to treat it differently from .git/config.\n\nThe former is user-specific, the latter is repository-specific.\n\nFor a contrived analogy: Imagine apache would ignore the contents\nof .htaccess files when you start httpd with the \"-f\" switch to\nload a different configuration file.\n\n> That makes the patch doubly suspect and throws it into \"because we can\",\n> not \"because we should\".\n> \n> Wouldn't it be just a matter of giving different HOME after they log-in?\n> \n> After all, Moe will be giving _some_ way to his users set different value\n> to GIT_CONFIG_EXTRA depending on who they really are, and that same\n> mechanism should be usable to set different HOME to them, no?\n\nThe individual users are identified by their ssh key. Ssh sets a\ndistinct environment variable for each, which in turn is used in\n.bash_profile to read an additional user-profile.\n\nYes, we could overwrite $HOME but that would defeat the purpose.\n\nThe goal of this setup is to share almost all settings.\nOverwriting $HOME would turn this upside down. Instead of diverting\nthe two bits that we want to customize (git identity and editor\npreferences) we would then have to duplicate all other dot-files\nfor each virtual user - and probably watch out for unforeseen side-effects.\n\n> As $HOME/.gitconfig is relative to the value of that environment variable,\n> I don't see a reason for us to fall into this \"three is not enough, but\n> when we add another, we are fine\" attitude, which makes me suspect that\n> there is something fundamentally wrong there.\n\nI understand the sentiment.\n\nWithout drifting into a discussion about the merit of shared\nunix-accounts (they do make a lot of sense in some scenarios)\nI hope this can still make it, considering the small size of\nthe patch and the .git/config vs ~/.gitconfig argument.\n\n\n-- \nKind regards, Moe\n"},{"id":"130123","messageId":"7vzl5fik3o.fsf@alter.siamese.dyndns.org","threadId":"21986","inReplyTo":"4B2C5A1A.8000201@signalbeam.net","subject":"Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-19T05:55:07Z","receivedAt":"2009-12-19T05:55:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Moe <moe@signalbeam.net> writes:\n\n>> I find the original use case highly moronic.\n>>\n>> For people to be sharing an account, hence $HOME, there must be a reason.\n>> They want to (rather, the administrator wants them to) use a common shared\n>> set of settings, so $HOME/.gitconfig should be shared among them, just\n>> like $HOME/.emacs and $HOME/.login are, unless there is some strong reason\n>> to treat .gitconfig any differently from all the other $HOME/.whatever\n>> files.  But I don't think there wasn't any argument to defend that.\n>\n> I'm not arguing to treat .gitconfig differently from other\n> dot-files, but to treat it differently from .git/config.\n>\n> The former is user-specific, the latter is repository-specific.\n\nThat is something we already do, like everybody else.  $HOME/.emacs is\nuser specific, /etc/emacs.d/* are site-wide, and \"Local Variables:..End:\"\nsection is per-document.  Have you asked emacs guys (and vim folks) about\na change similar to the one on topic here?  This question is rhetoric and\nyou do not have to answer it.\n\n>> Wouldn't it be just a matter of giving different HOME after they log-in?\n>> \n>> After all, Moe will be giving _some_ way to his users set different value\n>> to GIT_CONFIG_EXTRA depending on who they really are, and that same\n>> mechanism should be usable to set different HOME to them, no?\n>\n> The individual users are identified by their ssh key. Ssh sets a\n> distinct environment variable for each, which in turn is used in\n> .bash_profile to read an additional user-profile.\n>\n> Yes, we could overwrite $HOME but that would defeat the purpose.\n> The goal of this setup is to share almost all settings.\n\nYou haven't answered the crucial question, and repeating yourself is not\nan explanation.  I've already said sharing the account is to share things,\nyou know I understand you want to _share_.  I asked why $HOME/.gitconfig\nhas to be treated differently from others like $HOME/.mailrc, $HOME/.gitk,\netc. that are shared.  You are not answering the question.\n\nWhat makes $HOME/.gitconfig different from $HOME/.ssh/., $HOME/.vimrc, and\nall the other things?  Why do you want to share all the other dot files,\nmost of which lack the support for you to do the \"set-up\" you have to do\nin $HOME/.bashrc to switch based on something other than the UID (I would\ncall that a \"set-up\", not a \"hack\", because you have to do that\nsomewhere)?  Why do your users tolerate that they cannot have their own\nprivate $HOME/.rpmmacros nor $HOME/.newsrc but it is not Ok that they have\nto share $HOME/.gitconfig with others?\n\nKnowing that is very important for us, as $HOME/.gitconfig will not stay\nthe only thing you would need to single out with future versions of git.\n\nFor example, we have discussed a support for $HOME/.git-excludes that sits\nbetween $GIT_DIR/info/exclude and the file pointed at by core.excludesfile\nconfiguration variable.  Should it be shared, or separated?  Why?\n\nI do not want to count on you, who I have never seen on this list before,\nbeing around to ask if such a change would break your use case when the\nday comes.  If we do not know the _criteria_ you are using, the reason why\nyou want to single out $HOME/.gitconfig when it is Ok for your users to\nshare $HOME/.vimrc, we will not be able to make good design decisions to\nsupport this \"shared account\" configuration [*1*].  Will we introduce\nGIT_EXCLUDE_EXTRA at the time like Miklos added GIT_CONFIG_EXTRA?  Where\ndoes it end?\n\n> I hope this can still make it, considering the small size of\n> the patch and the .git/config vs ~/.gitconfig argument.\n\nThat is not an argument at all.  We handle .git/config vs $HOME/.gitconfig\njust fine; see above.\n\nOne plausible answer you could have given is that your users do not have\nan account in the usual sense of the word at all, and the _only_ thing\nthey can do with your system is to run git and nothing else.  IOW they\nhave no business with even having $HOME/.vimrc or $HOME/.rhosts, so these\nother dotfiles do not matter at all.  That makes $HOME/.gitconfig special.\n\nA possible solution might be for us to honor $GIT_HOME that is favoured\nover $HOME, just like $GIT_EDITOR overrides $EDITOR.  That allows us to\nextend the notion more naturally in the future.  For example, when we\nstart reading from $HOME/.git-excludes, if the GIT_HOME environment is\nset, we would instead read from $GIT_HOME/.git-excludes.  That would be a\nmuch cleaner solution than Miklos's patch [*2*].\n\nBut you have given us too little for us to be able to judge what the best\nlonger-term course of action is.  How could you even _hope_ it can \"make\nit\"?\n\n\n[Footnote]\n\n*1* Of course, before doing so, we need to decide if this \"shared account\"\nconfiguration makes sense or not to begin with, but you haven't given us\nenough to work with to even decide that.\n\n*2* I am not criticizing Miklos's patch in particular.  The patch was done\nin the same void without any usable information from you what you really\nneeded, so the lack of provision for future we can see in the patch is not\nMiklos's fault.  Also he is not the git maintainer and is not used to\nworry about the future like I do.\n"},{"id":"130126","messageId":"4B2C7EC3.6070501@signalbeam.net","threadId":"21986","inReplyTo":"7vzl5fik3o.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable","fromName":"Moe","fromEmail":"moe@signalbeam.net","sentAt":"2009-12-19T07:20:35Z","receivedAt":"2009-12-19T07:20:35Z","isPatch":true,"sender":{"key":"moe@signalbeam.net","avatar":null},"body":"Junio C Hamano wrote:\n> Moe <moe@signalbeam.net> writes:\n> \n>>> I find the original use case highly moronic.\n>>>\n>>> For people to be sharing an account, hence $HOME, there must be a reason.\n>>> They want to (rather, the administrator wants them to) use a common shared\n>>> set of settings, so $HOME/.gitconfig should be shared among them, just\n>>> like $HOME/.emacs and $HOME/.login are, unless there is some strong reason\n>>> to treat .gitconfig any differently from all the other $HOME/.whatever\n>>> files.  But I don't think there wasn't any argument to defend that.\n>> I'm not arguing to treat .gitconfig differently from other\n>> dot-files, but to treat it differently from .git/config.\n>>\n>> The former is user-specific, the latter is repository-specific.\n> \n> That is something we already do, like everybody else.  $HOME/.emacs is\n> user specific, /etc/emacs.d/* are site-wide, and \"Local Variables:..End:\"\n> section is per-document.  Have you asked emacs guys (and vim folks) about\n> a change similar to the one on topic here?  This question is rhetoric and\n> you do not have to answer it.\n> \n>>> Wouldn't it be just a matter of giving different HOME after they log-in?\n>>>\n>>> After all, Moe will be giving _some_ way to his users set different value\n>>> to GIT_CONFIG_EXTRA depending on who they really are, and that same\n>>> mechanism should be usable to set different HOME to them, no?\n>> The individual users are identified by their ssh key. Ssh sets a\n>> distinct environment variable for each, which in turn is used in\n>> .bash_profile to read an additional user-profile.\n>>\n>> Yes, we could overwrite $HOME but that would defeat the purpose.\n>> The goal of this setup is to share almost all settings.\n> \n> You haven't answered the crucial question, and repeating yourself is not\n> an explanation.  I've already said sharing the account is to share things,\n> you know I understand you want to _share_.  I asked why $HOME/.gitconfig\n> has to be treated differently from others like $HOME/.mailrc, $HOME/.gitk,\n> etc. that are shared.  You are not answering the question.\n\nI refrained from delving deeper into our particular use-case at first,\ndue to the verbosity and to avoid a potential \"git wasn't meant for\nthis\" knockout. But it seems we're over this, so see below.\n\n> What makes $HOME/.gitconfig different from $HOME/.ssh/., $HOME/.vimrc, and\n> all the other things?  Why do you want to share all the other dot files,\n> most of which lack the support for you to do the \"set-up\" you have to do\n> in $HOME/.bashrc to switch based on something other than the UID (I would\n> call that a \"set-up\", not a \"hack\", because you have to do that\n> somewhere)?  Why do your users tolerate that they cannot have their own\n> private $HOME/.rpmmacros nor $HOME/.newsrc but it is not Ok that they have\n> to share $HOME/.gitconfig with others?\n>\n> Knowing that is very important for us, as $HOME/.gitconfig will not stay\n> the only thing you would need to single out with future versions of git.\n> \n> For example, we have discussed a support for $HOME/.git-excludes that sits\n> between $GIT_DIR/info/exclude and the file pointed at by core.excludesfile\n> configuration variable.  Should it be shared, or separated?  Why?\n> \n> I do not want to count on you, who I have never seen on this list before,\n> being around to ask if such a change would break your use case when the\n> day comes.  If we do not know the _criteria_ you are using, the reason why\n> you want to single out $HOME/.gitconfig when it is Ok for your users to\n> share $HOME/.vimrc, we will not be able to make good design decisions to\n> support this \"shared account\" configuration [*1*].  Will we introduce\n> GIT_EXCLUDE_EXTRA at the time like Miklos added GIT_CONFIG_EXTRA?  Where\n> does it end?\n> \n>> I hope this can still make it, considering the small size of\n>> the patch and the .git/config vs ~/.gitconfig argument.\n> \n> That is not an argument at all.  We handle .git/config vs $HOME/.gitconfig\n> just fine; see above.\n> \n> One plausible answer you could have given is that your users do not have\n> an account in the usual sense of the word at all, and the _only_ thing\n> they can do with your system is to run git and nothing else.  IOW they\n> have no business with even having $HOME/.vimrc or $HOME/.rhosts, so these\n> other dotfiles do not matter at all.  That makes $HOME/.gitconfig special.\n\nYes, that's pretty close. What we do is, we put our entire runtime\nenvironment [for a web application] under a dedicated user and under\nversion control. This is a very comfortable way to maintain an\nidentical environment across the board, we even deploy this way\nto our production servers by the means of a git pull on a\ndedicated branch.\n\nIn practice our developers will su or ssh to this user to get working\nand generally they need only a very small set of divertions from the\ncommon configuration - such as their personal git identity and their\npreferred editor settings.\n\nOne may argue that a bunch of host-specific symlinks could achieve a\nsimilar effect - and that would be correct - but having literally\neverything under version control yields certain advantages that we\nwouldn't want to miss. Such as any developer being able to ssh into\nthe shared user on any host and being right at home (including\nproperly attributed git commits) without further twiddling.\n(that usually comes into play when ssh'ing into a production host,\n performing a hotfix and feeding it back)\n\nThis all may seem esoteric or even moronic to you. All I can say is\nthat it's been working extraordinary well for us over the past 2 years,\ndespite the minor git inconvenience.\n\n> A possible solution might be for us to honor $GIT_HOME that is favoured\n> over $HOME, just like $GIT_EDITOR overrides $EDITOR.  That allows us to\n> extend the notion more naturally in the future.  For example, when we\n> start reading from $HOME/.git-excludes, if the GIT_HOME environment is\n> set, we would instead read from $GIT_HOME/.git-excludes.  That would be a\n> much cleaner solution than Miklos's patch [*2*].\n\nSounds like that would serve our case just as well\nand yes, probably much cleaner in the long run.\n\n> But you have given us too little for us to be able to judge what the best\n> longer-term course of action is.  How could you even _hope_ it can \"make\n> it\"?\n\nWell, sorry for being so brief initially. Being not as involved with git\ndevelopment I based my request on what I figured could be a\nsane generalization of our particular problem.\n\nAlso I don't mean to blow this out of proportion; it's a minor,\nmostly cosmetic inconvenience for us and we can stick to our workarounds\nor Miklos' patch if a mainline change shakes\nthings up too much.\n"},{"id":"130130","messageId":"alpine.DEB.1.00.0912191150450.4985@pacific.mpi-cbg.de","threadId":"21986","inReplyTo":"4B2C7EC3.6070501@signalbeam.net","subject":"Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-12-19T10:54:07Z","receivedAt":"2009-12-19T10:54:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 19 Dec 2009, Moe wrote:\n\n> What we do is, we put our entire runtime environment [for a web \n> application] under a dedicated user and under version control. This is a \n> very comfortable way to maintain an identical environment across the \n> board, we even deploy this way to our production servers by the means of \n> a git pull on a dedicated branch.\n\nJust ignoring the fact that you version control a version controlled \ndirectory (including the repository), which is inefficient, and even \nfurther ignoring the fact that you open the door for concurrent -- \nincompatible -- modifications, if all you want to do is:\n\n> In practice our developers will su or ssh to this user to get working \n> and generally they need only a very small set of divertions from the \n> common configuration - such as their personal git identity and their \n> preferred editor settings.\n\n... then I suggest reading up on GIT_EDITOR, GIT_AUTHOR_IDENT and \nGIT_COMMITTER_IDENT, and leaving the $HOME/.gitconfig alone.\n\nCiao,\nDscho\n"},{"id":"130133","messageId":"4B2CBB53.5000804@signalbeam.net","threadId":"21986","inReplyTo":"alpine.DEB.1.00.0912191150450.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable","fromName":"Moe","fromEmail":"moe@signalbeam.net","sentAt":"2009-12-19T11:38:59Z","receivedAt":"2009-12-19T11:38:59Z","isPatch":true,"sender":{"key":"moe@signalbeam.net","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Sat, 19 Dec 2009, Moe wrote:\n> \n>> What we do is, we put our entire runtime environment [for a web \n>> application] under a dedicated user and under version control. This is a \n>> very comfortable way to maintain an identical environment across the \n>> board, we even deploy this way to our production servers by the means of \n>> a git pull on a dedicated branch.\n> \n> Just ignoring the fact that you version control a version controlled \n> directory (including the repository), which is inefficient, and even \n> further ignoring the fact that you open the door for concurrent -- \n> incompatible -- modifications, if all you want to do is:\n\nNeither is true.\n\n>> In practice our developers will su or ssh to this user to get working \n>> and generally they need only a very small set of divertions from the \n>> common configuration - such as their personal git identity and their \n>> preferred editor settings.\n> \n> ... then I suggest reading up on GIT_EDITOR, GIT_AUTHOR_IDENT and \n> GIT_COMMITTER_IDENT, and leaving the $HOME/.gitconfig alone.\n\nThanks, that solved my problem.\nSeems I started by asking the wrong question.\n"},{"id":"130141","messageId":"20091219142559.GF25474@genesis.frugalware.org","threadId":"21986","inReplyTo":"20091219020947.GB10687@spearce.org","subject":"Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2009-12-19T14:25:59Z","receivedAt":"2009-12-19T14:25:59Z","isPatch":true,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Fri, Dec 18, 2009 at 06:09:47PM -0800, \"Shawn O. Pearce\" <spearce@spearce.org> wrote:\n> What file does `git config --add` modify?  Should we be able to\n> modify the GIT_CONFIG_EXTRA file?\n\ngit config --add will still write .git/config (or $GIT_CONFIG) as\nbefore. At the moment there is no way to modify a GIT_CONFIG_EXTRA file\nusing git-config.\n\n> What order is GIT_CONFIG_EXTRA applied in relative to other files\n> that git config would also have read?\n\nThe config file from GIT_CONFIG_EXTRA is the last one that is read.\n\nAdding the above feature and documenting the later answer could be done\nin a second version of such a patch, but as far as I see it's no good\ndoing so because then patch solves a non-exsiting problem. ;-)\n"},{"id":"130142","messageId":"20091219234501.6117@nanako3.lavabit.com","threadId":"21986","inReplyTo":"4B2C7EC3.6070501@signalbeam.net","subject":"Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-12-19T14:45:01Z","receivedAt":"2009-12-19T14:45:01Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Moe <moe@signalbeam.net>\n\n> In practice our developers will su or ssh to this user to get working\n> and generally they need only a very small set of divertions from the\n> common configuration - such as their personal git identity and their\n> preferred editor settings.\n\nDo \"preferred editor settings\" mean $HOME/.vim that was one of \nJunio's examples? How do you handle it?\n\nIt sounds like you are only interested in user.name and \nuser.email, and you don't need to override $HOME/.gitconfig as \na whole.  Because you already have a section in $HOME/.bashrc \nthat does different things based on the user's SSH key, you \nmay want to set variables GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL \nin there without doing anything else if that is the case.\n\n> One may argue that a bunch of host-specific symlinks could achieve a\n> similar effect - and that would be correct - but having literally\n> everything under version control yields certain advantages that we\n> wouldn't want to miss.\n\nSorry, but I don't understand. What do symlinks have to do \nwith keeping everything under version control? git can track \nsymbolic links just fine, if that is what is troubling you.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"130143","messageId":"20091219153046.GG25474@genesis.frugalware.org","threadId":"21986","inReplyTo":"7vzl5fik3o.fsf@alter.siamese.dyndns.org","subject":"[PATCH] Introduce the GIT_HOME environment variable","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2009-12-19T15:30:46Z","receivedAt":"2009-12-19T15:30:46Z","isPatch":true,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"Honor $GIT_HOME that is favoured over $HOME, just like $GIT_EDITOR\noverrides $EDITOR.  That allows us to extend the notion more naturally\nin the future.  For example, when we start reading from\n$HOME/.gitconfig, if the GIT_HOME environment is set, we would instead\nread from $GIT_HOME/.gitconfig.\n\nSigned-off-by: Miklos Vajna <vmiklos@frugalware.org>\n---\n\nOn Fri, Dec 18, 2009 at 09:55:07PM -0800, Junio C Hamano <gitster@pobox.com> wrote:\n> A possible solution might be for us to honor $GIT_HOME that is favoured\n> over $HOME, just like $GIT_EDITOR overrides $EDITOR.  That allows us to\n> extend the notion more naturally in the future.  For example, when we\n> start reading from $HOME/.git-excludes, if the GIT_HOME environment is\n> set, we would instead read from $GIT_HOME/.git-excludes.  That would be a\n> much cleaner solution than Miklos's patch [*2*].\n\nSomething like this?\n\nI've stolen most of the commit message from your mail. ;-)\n\n Documentation/config.txt |   14 ++++++++++----\n builtin-config.c         |    8 ++++++--\n config.c                 |    4 +++-\n path.c                   |    4 +++-\n t/t1300-repo-config.sh   |    7 +++++++\n 5 files changed, 29 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex a1e36d7..09cbc71 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -8,6 +8,10 @@ is used to store the configuration for that repository, and\n fallback values for the `.git/config` file. The file `/etc/gitconfig`\n can be used to store a system-wide default configuration.\n \n+In case you want to store your per-user configuration in a directory\n+different to `$HOME`, you can use the `$GIT_HOME` environment variable\n+which has preference.\n+\n The configuration variables are used by both the git plumbing\n and the porcelains. The variables are divided into sections, wherein\n the fully qualified variable name of the variable itself is the last\n@@ -406,8 +410,9 @@ core.excludesfile::\n \tIn addition to '.gitignore' (per-directory) and\n \t'.git/info/exclude', git looks into this file for patterns\n \tof files which are not meant to be tracked.  \"{tilde}/\" is expanded\n-\tto the value of `$HOME` and \"{tilde}user/\" to the specified user's\n-\thome directory.  See linkgit:gitignore[5].\n+\tto the value of `$GIT_HOME` (or `$HOME` if `$GIT_HOME` is not\n+\tset) and \"{tilde}user/\" to the specified user's home directory.  See\n+\tlinkgit:gitignore[5].\n \n core.editor::\n \tCommands such as `commit` and `tag` that lets you edit\n@@ -707,8 +712,9 @@ color.ui::\n \n commit.template::\n \tSpecify a file to use as the template for new commit messages.\n-\t\"{tilde}/\" is expanded to the value of `$HOME` and \"{tilde}user/\" to the\n-\tspecified user's home directory.\n+\t\"{tilde}/\" is expanded to the value of `$GIT_HOME` (or `$HOME`\n+\tif `$GIT_HOME` is not set) and \"{tilde}user/\" to the specified user's\n+\thome directory.\n \n diff.autorefreshindex::\n \tWhen using 'git-diff' to compare with work tree\ndiff --git a/builtin-config.c b/builtin-config.c\nindex a2d656e..da9ebd4 100644\n--- a/builtin-config.c\n+++ b/builtin-config.c\n@@ -146,7 +146,9 @@ static int get_value(const char *key_, const char *regex_)\n \n \tlocal = config_exclusive_filename;\n \tif (!local) {\n-\t\tconst char *home = getenv(\"HOME\");\n+\t\tconst char *home = getenv(\"GIT_HOME\");\n+\t\tif (!home)\n+\t\t\thome = getenv(\"HOME\");\n \t\tlocal = repo_config = git_pathdup(\"config\");\n \t\tif (git_config_global() && home)\n \t\t\tglobal = xstrdup(mkpath(\"%s/.gitconfig\", home));\n@@ -326,7 +328,9 @@ int cmd_config(int argc, const char **argv, const char *unused_prefix)\n \t}\n \n \tif (use_global_config) {\n-\t\tchar *home = getenv(\"HOME\");\n+\t\tchar *home = getenv(\"GIT_HOME\");\n+\t\tif (!home)\n+\t\t\thome = getenv(\"HOME\");\n \t\tif (home) {\n \t\t\tchar *user_config = xstrdup(mkpath(\"%s/.gitconfig\", home));\n \t\t\tconfig_exclusive_filename = user_config;\ndiff --git a/config.c b/config.c\nindex 37385ce..7e2ccdb 100644\n--- a/config.c\n+++ b/config.c\n@@ -711,7 +711,9 @@ int git_config(config_fn_t fn, void *data)\n \t\tfound += 1;\n \t}\n \n-\thome = getenv(\"HOME\");\n+\thome = getenv(\"GIT_HOME\");\n+\tif (!home)\n+\t\thome = getenv(\"HOME\");\n \tif (git_config_global() && home) {\n \t\tchar *user_config = xstrdup(mkpath(\"%s/.gitconfig\", home));\n \t\tif (!access(user_config, R_OK)) {\ndiff --git a/path.c b/path.c\nindex 2ec950b..b42a1b6 100644\n--- a/path.c\n+++ b/path.c\n@@ -236,7 +236,9 @@ char *expand_user_path(const char *path)\n \t\tconst char *username = path + 1;\n \t\tsize_t username_len = first_slash - username;\n \t\tif (username_len == 0) {\n-\t\t\tconst char *home = getenv(\"HOME\");\n+\t\t\tconst char *home = getenv(\"GIT_HOME\");\n+\t\t\tif (!home)\n+\t\t\t\thome = getenv(\"HOME\");\n \t\t\tstrbuf_add(&user_path, home, strlen(home));\n \t\t} else {\n \t\t\tstruct passwd *pw = getpw_str(username, username_len);\ndiff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh\nindex 83b7294..d9818ab 100755\n--- a/t/t1300-repo-config.sh\n+++ b/t/t1300-repo-config.sh\n@@ -18,6 +18,13 @@ EOF\n \n test_expect_success 'initial' 'cmp .git/config expect'\n \n+test_expect_success 'GIT_HOME' '\n+\tGIT_HOME=\"`pwd`\" &&\n+\texport GIT_HOME &&\n+\tgit config --global core.penguin \"little blue\" &&\n+\tcmp \"$GIT_HOME\"/.gitconfig expect\n+'\n+\n git config Core.Movie BadPhysics\n \n cat > expect << EOF\n-- \n1.6.5.2\n"},{"id":"130144","messageId":"4B2CFCD1.3010208@drmicha.warpmail.net","threadId":"21986","inReplyTo":"20091219153046.GG25474@genesis.frugalware.org","subject":"Re: [PATCH] Introduce the GIT_HOME environment variable","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-12-19T16:18:25Z","receivedAt":"2009-12-19T16:18:25Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Miklos Vajna venit, vidit, dixit 19.12.2009 16:30:\n> Honor $GIT_HOME that is favoured over $HOME, just like $GIT_EDITOR\n> overrides $EDITOR.  That allows us to extend the notion more naturally\n> in the future.  For example, when we start reading from\n> $HOME/.gitconfig, if the GIT_HOME environment is set, we would instead\n> read from $GIT_HOME/.gitconfig.\n> \n> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>\n> ---\n> \n> On Fri, Dec 18, 2009 at 09:55:07PM -0800, Junio C Hamano <gitster@pobox.com> wrote:\n>> A possible solution might be for us to honor $GIT_HOME that is favoured\n>> over $HOME, just like $GIT_EDITOR overrides $EDITOR.  That allows us to\n>> extend the notion more naturally in the future.  For example, when we\n>> start reading from $HOME/.git-excludes, if the GIT_HOME environment is\n>> set, we would instead read from $GIT_HOME/.git-excludes.  That would be a\n>> much cleaner solution than Miklos's patch [*2*].\n> \n> Something like this?\n> \n> I've stolen most of the commit message from your mail. ;-)\n\nYes, but it makes less sense this way... Junio wrote \"when we start\nreading\" because we don't do that yet. But we read ~/.gitconfig, of\ncourse, so \"when we start reading\" sounds funny here.\n\n> \n>  Documentation/config.txt |   14 ++++++++++----\n>  builtin-config.c         |    8 ++++++--\n>  config.c                 |    4 +++-\n>  path.c                   |    4 +++-\n>  t/t1300-repo-config.sh   |    7 +++++++\n>  5 files changed, 29 insertions(+), 8 deletions(-)\n> \n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index a1e36d7..09cbc71 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -8,6 +8,10 @@ is used to store the configuration for that repository, and\n>  fallback values for the `.git/config` file. The file `/etc/gitconfig`\n>  can be used to store a system-wide default configuration.\n>  \n> +In case you want to store your per-user configuration in a directory\n> +different to `$HOME`, you can use the `$GIT_HOME` environment variable\n\n\"different from\"\n\n> +which has preference.\n> +\n>  The configuration variables are used by both the git plumbing\n>  and the porcelains. The variables are divided into sections, wherein\n>  the fully qualified variable name of the variable itself is the last\n> @@ -406,8 +410,9 @@ core.excludesfile::\n>  \tIn addition to '.gitignore' (per-directory) and\n>  \t'.git/info/exclude', git looks into this file for patterns\n>  \tof files which are not meant to be tracked.  \"{tilde}/\" is expanded\n> -\tto the value of `$HOME` and \"{tilde}user/\" to the specified user's\n> -\thome directory.  See linkgit:gitignore[5].\n> +\tto the value of `$GIT_HOME` (or `$HOME` if `$GIT_HOME` is not\n> +\tset) and \"{tilde}user/\" to the specified user's home directory.  See\n> +\tlinkgit:gitignore[5].\n>  \n>  core.editor::\n>  \tCommands such as `commit` and `tag` that lets you edit\n> @@ -707,8 +712,9 @@ color.ui::\n>  \n>  commit.template::\n>  \tSpecify a file to use as the template for new commit messages.\n> -\t\"{tilde}/\" is expanded to the value of `$HOME` and \"{tilde}user/\" to the\n> -\tspecified user's home directory.\n> +\t\"{tilde}/\" is expanded to the value of `$GIT_HOME` (or `$HOME`\n> +\tif `$GIT_HOME` is not set) and \"{tilde}user/\" to the specified user's\n> +\thome directory.\n>  \n>  diff.autorefreshindex::\n>  \tWhen using 'git-diff' to compare with work tree\n> diff --git a/builtin-config.c b/builtin-config.c\n> index a2d656e..da9ebd4 100644\n> --- a/builtin-config.c\n> +++ b/builtin-config.c\n> @@ -146,7 +146,9 @@ static int get_value(const char *key_, const char *regex_)\n>  \n>  \tlocal = config_exclusive_filename;\n>  \tif (!local) {\n> -\t\tconst char *home = getenv(\"HOME\");\n> +\t\tconst char *home = getenv(\"GIT_HOME\");\n> +\t\tif (!home)\n> +\t\t\thome = getenv(\"HOME\");\n>  \t\tlocal = repo_config = git_pathdup(\"config\");\n>  \t\tif (git_config_global() && home)\n>  \t\t\tglobal = xstrdup(mkpath(\"%s/.gitconfig\", home));\n> @@ -326,7 +328,9 @@ int cmd_config(int argc, const char **argv, const char *unused_prefix)\n>  \t}\n>  \n>  \tif (use_global_config) {\n> -\t\tchar *home = getenv(\"HOME\");\n> +\t\tchar *home = getenv(\"GIT_HOME\");\n> +\t\tif (!home)\n> +\t\t\thome = getenv(\"HOME\");\n>  \t\tif (home) {\n>  \t\t\tchar *user_config = xstrdup(mkpath(\"%s/.gitconfig\", home));\n>  \t\t\tconfig_exclusive_filename = user_config;\n> diff --git a/config.c b/config.c\n> index 37385ce..7e2ccdb 100644\n> --- a/config.c\n> +++ b/config.c\n> @@ -711,7 +711,9 @@ int git_config(config_fn_t fn, void *data)\n>  \t\tfound += 1;\n>  \t}\n>  \n> -\thome = getenv(\"HOME\");\n> +\thome = getenv(\"GIT_HOME\");\n> +\tif (!home)\n> +\t\thome = getenv(\"HOME\");\n>  \tif (git_config_global() && home) {\n>  \t\tchar *user_config = xstrdup(mkpath(\"%s/.gitconfig\", home));\n>  \t\tif (!access(user_config, R_OK)) {\n> diff --git a/path.c b/path.c\n> index 2ec950b..b42a1b6 100644\n> --- a/path.c\n> +++ b/path.c\n> @@ -236,7 +236,9 @@ char *expand_user_path(const char *path)\n>  \t\tconst char *username = path + 1;\n>  \t\tsize_t username_len = first_slash - username;\n>  \t\tif (username_len == 0) {\n> -\t\t\tconst char *home = getenv(\"HOME\");\n> +\t\t\tconst char *home = getenv(\"GIT_HOME\");\n> +\t\t\tif (!home)\n> +\t\t\t\thome = getenv(\"HOME\");\n>  \t\t\tstrbuf_add(&user_path, home, strlen(home));\n>  \t\t} else {\n>  \t\t\tstruct passwd *pw = getpw_str(username, username_len);\n> diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh\n> index 83b7294..d9818ab 100755\n> --- a/t/t1300-repo-config.sh\n> +++ b/t/t1300-repo-config.sh\n> @@ -18,6 +18,13 @@ EOF\n>  \n>  test_expect_success 'initial' 'cmp .git/config expect'\n>  \n> +test_expect_success 'GIT_HOME' '\n> +\tGIT_HOME=\"`pwd`\" &&\n> +\texport GIT_HOME &&\n> +\tgit config --global core.penguin \"little blue\" &&\n> +\tcmp \"$GIT_HOME\"/.gitconfig expect\n> +'\n> +\n>  git config Core.Movie BadPhysics\n>  \n>  cat > expect << EOF\n"},{"id":"130153","messageId":"20091219164454.GJ25474@genesis.frugalware.org","threadId":"21986","inReplyTo":"4B2CFCD1.3010208@drmicha.warpmail.net","subject":"[PATCH] Introduce the GIT_HOME environment variable","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2009-12-19T16:44:54Z","receivedAt":"2009-12-19T16:44:54Z","isPatch":true,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"Honor $GIT_HOME that is favoured over $HOME, just like $GIT_EDITOR\noverrides $EDITOR.  That allows us to extend the notion more naturally\nin the future.  For example, when we read from $HOME/.gitconfig, if the\nGIT_HOME environment is set, we instead read from $GIT_HOME/.gitconfig.\n\nSigned-off-by: Miklos Vajna <vmiklos@frugalware.org>\n---\n\nOn Sat, Dec 19, 2009 at 05:18:25PM +0100, Michael J Gruber <git@drmicha.warpmail.net> wrote:\n> Yes, but it makes less sense this way... Junio wrote \"when we start\n> reading\" because we don't do that yet. But we read ~/.gitconfig, of\n> course, so \"when we start reading\" sounds funny here.\n>\n> (...)\n>\n> \"different from\"\n\nFixed both, thanks.\n\n Documentation/config.txt |   14 ++++++++++----\n builtin-config.c         |    8 ++++++--\n config.c                 |    4 +++-\n path.c                   |    4 +++-\n t/t1300-repo-config.sh   |    7 +++++++\n 5 files changed, 29 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex a1e36d7..09cbc71 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -8,6 +8,10 @@ is used to store the configuration for that repository, and\n fallback values for the `.git/config` file. The file `/etc/gitconfig`\n can be used to store a system-wide default configuration.\n \n+In case you want to store your per-user configuration in a directory\n+different from `$HOME`, you can use the `$GIT_HOME` environment variable\n+which has preference.\n+\n The configuration variables are used by both the git plumbing\n and the porcelains. The variables are divided into sections, wherein\n the fully qualified variable name of the variable itself is the last\n@@ -406,8 +410,9 @@ core.excludesfile::\n \tIn addition to '.gitignore' (per-directory) and\n \t'.git/info/exclude', git looks into this file for patterns\n \tof files which are not meant to be tracked.  \"{tilde}/\" is expanded\n-\tto the value of `$HOME` and \"{tilde}user/\" to the specified user's\n-\thome directory.  See linkgit:gitignore[5].\n+\tto the value of `$GIT_HOME` (or `$HOME` if `$GIT_HOME` is not\n+\tset) and \"{tilde}user/\" to the specified user's home directory.  See\n+\tlinkgit:gitignore[5].\n \n core.editor::\n \tCommands such as `commit` and `tag` that lets you edit\n@@ -707,8 +712,9 @@ color.ui::\n \n commit.template::\n \tSpecify a file to use as the template for new commit messages.\n-\t\"{tilde}/\" is expanded to the value of `$HOME` and \"{tilde}user/\" to the\n-\tspecified user's home directory.\n+\t\"{tilde}/\" is expanded to the value of `$GIT_HOME` (or `$HOME`\n+\tif `$GIT_HOME` is not set) and \"{tilde}user/\" to the specified user's\n+\thome directory.\n \n diff.autorefreshindex::\n \tWhen using 'git-diff' to compare with work tree\ndiff --git a/builtin-config.c b/builtin-config.c\nindex a2d656e..da9ebd4 100644\n--- a/builtin-config.c\n+++ b/builtin-config.c\n@@ -146,7 +146,9 @@ static int get_value(const char *key_, const char *regex_)\n \n \tlocal = config_exclusive_filename;\n \tif (!local) {\n-\t\tconst char *home = getenv(\"HOME\");\n+\t\tconst char *home = getenv(\"GIT_HOME\");\n+\t\tif (!home)\n+\t\t\thome = getenv(\"HOME\");\n \t\tlocal = repo_config = git_pathdup(\"config\");\n \t\tif (git_config_global() && home)\n \t\t\tglobal = xstrdup(mkpath(\"%s/.gitconfig\", home));\n@@ -326,7 +328,9 @@ int cmd_config(int argc, const char **argv, const char *unused_prefix)\n \t}\n \n \tif (use_global_config) {\n-\t\tchar *home = getenv(\"HOME\");\n+\t\tchar *home = getenv(\"GIT_HOME\");\n+\t\tif (!home)\n+\t\t\thome = getenv(\"HOME\");\n \t\tif (home) {\n \t\t\tchar *user_config = xstrdup(mkpath(\"%s/.gitconfig\", home));\n \t\t\tconfig_exclusive_filename = user_config;\ndiff --git a/config.c b/config.c\nindex 37385ce..7e2ccdb 100644\n--- a/config.c\n+++ b/config.c\n@@ -711,7 +711,9 @@ int git_config(config_fn_t fn, void *data)\n \t\tfound += 1;\n \t}\n \n-\thome = getenv(\"HOME\");\n+\thome = getenv(\"GIT_HOME\");\n+\tif (!home)\n+\t\thome = getenv(\"HOME\");\n \tif (git_config_global() && home) {\n \t\tchar *user_config = xstrdup(mkpath(\"%s/.gitconfig\", home));\n \t\tif (!access(user_config, R_OK)) {\ndiff --git a/path.c b/path.c\nindex 2ec950b..b42a1b6 100644\n--- a/path.c\n+++ b/path.c\n@@ -236,7 +236,9 @@ char *expand_user_path(const char *path)\n \t\tconst char *username = path + 1;\n \t\tsize_t username_len = first_slash - username;\n \t\tif (username_len == 0) {\n-\t\t\tconst char *home = getenv(\"HOME\");\n+\t\t\tconst char *home = getenv(\"GIT_HOME\");\n+\t\t\tif (!home)\n+\t\t\t\thome = getenv(\"HOME\");\n \t\t\tstrbuf_add(&user_path, home, strlen(home));\n \t\t} else {\n \t\t\tstruct passwd *pw = getpw_str(username, username_len);\ndiff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh\nindex 83b7294..d9818ab 100755\n--- a/t/t1300-repo-config.sh\n+++ b/t/t1300-repo-config.sh\n@@ -18,6 +18,13 @@ EOF\n \n test_expect_success 'initial' 'cmp .git/config expect'\n \n+test_expect_success 'GIT_HOME' '\n+\tGIT_HOME=\"`pwd`\" &&\n+\texport GIT_HOME &&\n+\tgit config --global core.penguin \"little blue\" &&\n+\tcmp \"$GIT_HOME\"/.gitconfig expect\n+'\n+\n git config Core.Movie BadPhysics\n \n cat > expect << EOF\n-- \n1.6.5.2\n"},{"id":"130154","messageId":"vpqeimq51pq.fsf@bauges.imag.fr","threadId":"21986","inReplyTo":"20091219153046.GG25474@genesis.frugalware.org","subject":"Re: [PATCH] Introduce the GIT_HOME environment variable","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2009-12-19T17:10:41Z","receivedAt":"2009-12-19T17:10:41Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Miklos Vajna <vmiklos@frugalware.org> writes:\n\n> Honor $GIT_HOME that is favoured over $HOME,\n\nI'd personally prefer obeying $XDG_CONFIG_HOME, and read\n$XDG_CONFIG_HOME/git/config (defaulting to $HOME/.config/git/config)\nor something like this :\n\nhttp://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html\n\nIt solves the same problem (\"set on environment variable, and change\nmy whole Git config\"), but\n\n* It's a standard. It's really nice to be able to\n\ncd ~/.config\nls\n\nto see a user's configuration for many applications at a time, and\n\ncd ~/.config\ngit init\n\nto version-control it.\n\n* It avoids hidden files. With $GIT_CONFIG, a user doing\n\ncd $GIT_HOME\nls\n\nsees nothing. I understand why $HOME/something config files are\nhidden, but a config file stored in a separate directory shouldn't be\nhidden (just like $GIT_DIR/config is not hidden).\n\n> -\t\tconst char *home = getenv(\"HOME\");\n> +\t\tconst char *home = getenv(\"GIT_HOME\");\n> +\t\tif (!home)\n> +\t\t\thome = getenv(\"HOME\");\n\nIf you go this way, why not define\n\nconst char *getenv_home()\n{\n\tconst char *home = getenv(\"GIT_HOME\");\n\tif (!home)\n\t\thome = getenv(\"HOME\");\n\treturn home;\n}\n\n?\n\n(probably in git-compat-util.h)\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"130155","messageId":"7vskb6bwvu.fsf@alter.siamese.dyndns.org","threadId":"21986","inReplyTo":"vpqeimq51pq.fsf@bauges.imag.fr","subject":"Re: [PATCH] Introduce the GIT_HOME environment variable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-19T19:13:09Z","receivedAt":"2009-12-19T19:13:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html\n>\n> It solves the same problem (\"set on environment variable, and change\n> my whole Git config\"), but\n>\n> * It's a standard. It's really nice to be able to ...\n> * It avoids hidden files. With $GIT_CONFIG, a user doing\n\nI think the above are actually three bullet points (i.e. you lack line\nbreak and bullet before \"It's really nice\").  And the third bullet is more\nor less a small subset of the second one, since you need \"ls -a\" without\nmaking them non-dot,  And I personally don't care very much about that\nsecond \"It's really nice to be able to\" point.\n\nAs to the particular \"standard\" cited, I don't know how relevant it is to\nus at this moment, or in this topic.  Judging from the fact that it\ndoesn't even define the scope of the standard (e.g. what classes of\napplications are expected to follow it, for what benefit do they follow\nit, how are they expected to handle differences between their historical\npractice and the new world order it introduces, etc. etc....), I suspect\nit is a very early draft that will be heavily copyedited before final,\nonce professional standard writers start looking at it.\n"},{"id":"130156","messageId":"7vhbrmahwq.fsf@alter.siamese.dyndns.org","threadId":"21986","inReplyTo":"20091219153046.GG25474@genesis.frugalware.org","subject":"Re: [PATCH] Introduce the GIT_HOME environment variable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-19T19:21:57Z","receivedAt":"2009-12-19T19:21:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miklos Vajna <vmiklos@frugalware.org> writes:\n\n> diff --git a/builtin-config.c b/builtin-config.c\n> index a2d656e..da9ebd4 100644\n> --- a/builtin-config.c\n> +++ b/builtin-config.c\n> @@ -146,7 +146,9 @@ static int get_value(const char *key_, const char *regex_)\n>  \n>  \tlocal = config_exclusive_filename;\n>  \tif (!local) {\n> -\t\tconst char *home = getenv(\"HOME\");\n> +\t\tconst char *home = getenv(\"GIT_HOME\");\n> +\t\tif (!home)\n> +\t\t\thome = getenv(\"HOME\");\n\nIf you introduce a helper like this:\n\n\tconst char *git_custom_home(void)\n        {\n        \tconst char *val = getenv(\"GIT_HOME\");\n                if (!val)\n                \tval = getenv(\"HOME\");\n\t\treturn val;\n\t}\n\nthen a mechanical s/getenv(\"GIT_HOME\")/gitcustom_home()/; will make the\nresulting code a lot simpler and a new callsite somebody may add in the\nfuture would not have to duplicate three lines.\n\nBut I sense that Moe is retracting his claim that the unmodified git\ndoesn't do what he needs to do, after Dscho suggested to use more specific\nenvironment variables to the task at hand?\n"},{"id":"130171","messageId":"20091220003433.GM25474@genesis.frugalware.org","threadId":"21986","inReplyTo":"7vhbrmahwq.fsf@alter.siamese.dyndns.org","subject":"[PATCH] Introduce the GIT_HOME environment variable","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2009-12-20T00:34:33Z","receivedAt":"2009-12-20T00:34:33Z","isPatch":true,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"Honor $GIT_HOME that is favoured over $HOME, just like $GIT_EDITOR\noverrides $EDITOR.  That allows us to extend the notion more naturally\nin the future.  For example, when we start reading from\n$HOME/.gitconfig, if the GIT_HOME environment is set, we would instead\nread from $GIT_HOME/.gitconfig.\n\nSigned-off-by: Miklos Vajna <vmiklos@frugalware.org>\n---\n\nOn Sat, Dec 19, 2009 at 11:21:57AM -0800, Junio C Hamano <gitster@pobox.com> wrote:\n> then a mechanical s/getenv(\"GIT_HOME\")/gitcustom_home()/; will make the\n> resulting code a lot simpler and a new callsite somebody may add in the\n> future would not have to duplicate three lines.\n\nDone.\n\n> But I sense that Moe is retracting his claim that the unmodified git\n> doesn't do what he needs to do, after Dscho suggested to use more specific\n> environment variables to the task at hand?\n\nI think Moe's problem is now solved by Dscho's suggestion, but this\npatch helps other users where the user-specific setting may contain\nother settings like diff.color (when $HOME is the same but GIT_HOME is\nset based on ssh keys).\n\n Documentation/config.txt |   14 ++++++++++----\n builtin-config.c         |    4 ++--\n config.c                 |    2 +-\n git-compat-util.h        |    2 ++\n path.c                   |    2 +-\n t/t1300-repo-config.sh   |    7 +++++++\n wrapper.c                |    7 +++++++\n 7 files changed, 30 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex a1e36d7..09cbc71 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -8,6 +8,10 @@ is used to store the configuration for that repository, and\n fallback values for the `.git/config` file. The file `/etc/gitconfig`\n can be used to store a system-wide default configuration.\n \n+In case you want to store your per-user configuration in a directory\n+different to `$HOME`, you can use the `$GIT_HOME` environment variable\n+which has preference.\n+\n The configuration variables are used by both the git plumbing\n and the porcelains. The variables are divided into sections, wherein\n the fully qualified variable name of the variable itself is the last\n@@ -406,8 +410,9 @@ core.excludesfile::\n \tIn addition to '.gitignore' (per-directory) and\n \t'.git/info/exclude', git looks into this file for patterns\n \tof files which are not meant to be tracked.  \"{tilde}/\" is expanded\n-\tto the value of `$HOME` and \"{tilde}user/\" to the specified user's\n-\thome directory.  See linkgit:gitignore[5].\n+\tto the value of `$GIT_HOME` (or `$HOME` if `$GIT_HOME` is not\n+\tset) and \"{tilde}user/\" to the specified user's home directory.  See\n+\tlinkgit:gitignore[5].\n \n core.editor::\n \tCommands such as `commit` and `tag` that lets you edit\n@@ -707,8 +712,9 @@ color.ui::\n \n commit.template::\n \tSpecify a file to use as the template for new commit messages.\n-\t\"{tilde}/\" is expanded to the value of `$HOME` and \"{tilde}user/\" to the\n-\tspecified user's home directory.\n+\t\"{tilde}/\" is expanded to the value of `$GIT_HOME` (or `$HOME`\n+\tif `$GIT_HOME` is not set) and \"{tilde}user/\" to the specified user's\n+\thome directory.\n \n diff.autorefreshindex::\n \tWhen using 'git-diff' to compare with work tree\ndiff --git a/builtin-config.c b/builtin-config.c\nindex a2d656e..97284c6 100644\n--- a/builtin-config.c\n+++ b/builtin-config.c\n@@ -146,7 +146,7 @@ static int get_value(const char *key_, const char *regex_)\n \n \tlocal = config_exclusive_filename;\n \tif (!local) {\n-\t\tconst char *home = getenv(\"HOME\");\n+\t\tconst char *home = git_custom_home();\n \t\tlocal = repo_config = git_pathdup(\"config\");\n \t\tif (git_config_global() && home)\n \t\t\tglobal = xstrdup(mkpath(\"%s/.gitconfig\", home));\n@@ -326,7 +326,7 @@ int cmd_config(int argc, const char **argv, const char *unused_prefix)\n \t}\n \n \tif (use_global_config) {\n-\t\tchar *home = getenv(\"HOME\");\n+\t\tconst char *home = git_custom_home();\n \t\tif (home) {\n \t\t\tchar *user_config = xstrdup(mkpath(\"%s/.gitconfig\", home));\n \t\t\tconfig_exclusive_filename = user_config;\ndiff --git a/config.c b/config.c\nindex 37385ce..cb2add8 100644\n--- a/config.c\n+++ b/config.c\n@@ -711,7 +711,7 @@ int git_config(config_fn_t fn, void *data)\n \t\tfound += 1;\n \t}\n \n-\thome = getenv(\"HOME\");\n+\thome = git_custom_home();\n \tif (git_config_global() && home) {\n \t\tchar *user_config = xstrdup(mkpath(\"%s/.gitconfig\", home));\n \t\tif (!access(user_config, R_OK)) {\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex 5c59687..9f345da 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -465,4 +465,6 @@ void git_qsort(void *base, size_t nmemb, size_t size,\n  */\n int unlink_or_warn(const char *path);\n \n+const char *git_custom_home(void);\n+\n #endif\ndiff --git a/path.c b/path.c\nindex 2ec950b..6038a95 100644\n--- a/path.c\n+++ b/path.c\n@@ -236,7 +236,7 @@ char *expand_user_path(const char *path)\n \t\tconst char *username = path + 1;\n \t\tsize_t username_len = first_slash - username;\n \t\tif (username_len == 0) {\n-\t\t\tconst char *home = getenv(\"HOME\");\n+\t\t\tconst char *home = git_custom_home();\n \t\t\tstrbuf_add(&user_path, home, strlen(home));\n \t\t} else {\n \t\t\tstruct passwd *pw = getpw_str(username, username_len);\ndiff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh\nindex 83b7294..d9818ab 100755\n--- a/t/t1300-repo-config.sh\n+++ b/t/t1300-repo-config.sh\n@@ -18,6 +18,13 @@ EOF\n \n test_expect_success 'initial' 'cmp .git/config expect'\n \n+test_expect_success 'GIT_HOME' '\n+\tGIT_HOME=\"`pwd`\" &&\n+\texport GIT_HOME &&\n+\tgit config --global core.penguin \"little blue\" &&\n+\tcmp \"$GIT_HOME\"/.gitconfig expect\n+'\n+\n git config Core.Movie BadPhysics\n \n cat > expect << EOF\ndiff --git a/wrapper.c b/wrapper.c\nindex c9be140..b7f6649 100644\n--- a/wrapper.c\n+++ b/wrapper.c\n@@ -305,3 +305,10 @@ int unlink_or_warn(const char *file)\n \treturn rc;\n }\n \n+const char *git_custom_home(void)\n+{\n+\tconst char *val = getenv(\"GIT_HOME\");\n+\tif (!val)\n+\t\tval = getenv(\"HOME\");\n+\treturn val;\n+}\n-- \n1.6.5.2\n"},{"id":"130212","messageId":"vpqhbrkd3o6.fsf@bauges.imag.fr","threadId":"21986","inReplyTo":"7vskb6bwvu.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Introduce the GIT_HOME environment variable","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2009-12-21T10:25:45Z","receivedAt":"2009-12-21T10:25:45Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n>\n>> http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html\n>>\n>> It solves the same problem (\"set on environment variable, and change\n>> my whole Git config\"), but\n>>\n>> * It's a standard. It's really nice to be able to ...\n>> * It avoids hidden files. With $GIT_CONFIG, a user doing\n>\n> I think the above are actually three bullet points (i.e. you lack line\n> break and bullet before \"It's really nice\").\n\nNo, I don't.\n\nYou can do\n\n| cd ~/.config\n| ls\n| \n| to see a user's configuration for many applications at a time,\n\n_because_ it's a standard, and because it's followed by several\napplications.\n\n> And the third bullet is more or less a small subset of the second\n> one, since you need \"ls -a\" without making them non-dot,\n\nThe standard may not write black-on-white\n$XDG_CONFIG_HOME/subdir/filename _with filename being non-hidden_, but\nin practice, this is what's happening.\n\n> And I personally don't care very much about that second \"It's really\n> nice to be able to\" point.\n\nYou may not care about consistancy between applications, but I do.\nCurrently, to version-control my user's configuration, I have\n$HOME/etc containing my user's config files, and the actual config\nfiles are symlinks to it. If applications were agreeing on a directory\nwhere configuration files would be stored (is it is the case on\nsystems like MS Windows, and I think Mac OS), I would just had done\n\"cd this-config-directory; git init\".\n\nWith the proposed $GIT_HOME, I have a way to specify _Git_'s path to\nconfig files. Another application may propose $WHATEVER_ELSE_HOME, and\nyet another would say $HOME_YET_ANOTHER_ONE, and so on. There's a\nproposal to have a single environment variable for all this, why\nreject it?\n\n> As to the particular \"standard\" cited, I don't know how relevant it is to\n> us at this moment, or in this topic.  Judging from the fact that it\n> doesn't even define the scope of the standard (e.g. what classes of\n> applications are expected to follow it, for what benefit do they follow\n> it, how are they expected to handle differences between their historical\n> practice and the new world order it introduces, etc. etc....), I suspect\n> it is a very early draft that will be heavily copyedited before final,\n> once professional standard writers start looking at it.\n\nI mostly agree on the critics, but do you have any better \"standard\"\n(actually, not necessarily an official standard, but \"something that\nvarious applications can agree on\") to propose?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"130217","messageId":"20091221155902.GA22665@sigill.intra.peff.net","threadId":"21986","inReplyTo":"vpqhbrkd3o6.fsf@bauges.imag.fr","subject":"Re: [PATCH] Introduce the GIT_HOME environment variable","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-12-21T15:59:02Z","receivedAt":"2009-12-21T15:59:02Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 21, 2009 at 11:25:45AM +0100, Matthieu Moy wrote:\n\n> You may not care about consistancy between applications, but I do.\n> Currently, to version-control my user's configuration, I have\n> $HOME/etc containing my user's config files, and the actual config\n> files are symlinks to it. If applications were agreeing on a directory\n> where configuration files would be stored (is it is the case on\n> systems like MS Windows, and I think Mac OS), I would just had done\n> \"cd this-config-directory; git init\".\n\nAre we even close to having this sort of universal support for\n~/.config? I also keep my dot-files in a git repository. I don't have a\nsingle one in ~/.config[1], but I do have ~/.profile, ~/.vimrc,\n~/.netrc, ~/.gitconfig, and others[2]. Traditionally, the standard for\nUnix has been for config files to be $HOME/.something. You can argue\nthat ~/.config is a better standard, but I don't think git is failing to\nuse a standard; it is simply following a different one.\n\n[1] I'll grant that is probably because I am a curmudgeon, and spend 99%\n    of my computing time in xterm+bash+vim.\n\n[2] Don't even get me started on ~/.mozilla/firefox/$RAND_HEX.default/user.js.\n\n> With the proposed $GIT_HOME, I have a way to specify _Git_'s path to\n> config files. Another application may propose $WHATEVER_ELSE_HOME, and\n> yet another would say $HOME_YET_ANOTHER_ONE, and so on. There's a\n> proposal to have a single environment variable for all this, why\n> reject it?\n\nBut we do have such a variable: $HOME. The concept of $GIT_HOME was\nproposed to provide a way to divert _just_ git to a different config\ndirectory, something that would not be any easier with $XDG_CONFIG_HOME.\n\n\nAnyway, as far as the future of git goes, even if we did want to switch\nto $XDG_CONFIG_HOME, we could not do so suddenly without breaking\neverybody's current setup. Which would mean any implementation of it\nwould have to handle both the current and the new proposed locations.\nYou can obviously just read from both, but there are a lot of open\nquestions, like \"which should take precedence?\" and \"what does git\nconfig --global --edit do?\". I am not opposed to hearing a clever\nproposal that handles all such issues, but I am not going to think too\nhard about it myself. :)\n\n-Peff\n"},{"id":"130218","messageId":"vpqskb49tuq.fsf@bauges.imag.fr","threadId":"21986","inReplyTo":"20091221155902.GA22665@sigill.intra.peff.net","subject":"Re: [PATCH] Introduce the GIT_HOME environment variable","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2009-12-21T16:26:05Z","receivedAt":"2009-12-21T16:26:05Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King <peff@peff.net> writes:\n\n> Are we even close to having this sort of universal support for\n> ~/.config?\n\nDefinitely not universal as of now. Probably precisely because each\napplication thinks \"I'll take care of $XDG_CONFIG_HOME after others\ndo\" ;-).\n\n> Traditionally, the standard for Unix\n> has been for config files to be $HOME/.something. You can argue that\n> ~/.config is a better standard, but I don't think git is failing to\n> use a standard; it is simply following a different one.\n\nI've probably been unclear about this. I'm not arguing about moving\naway from $HOME/.gitconfig as the default (IOW, we're in agreement\nhere ;-) ). It's there, and the migration path would be much more\npainfull than the benefit.\n\nWhat I'm saying is that _if_ we introduce a variable to point to an\nalternate .gitconfig, then we should use something like\n$XDG_CONFIG_HOME/git/config and not $GIT_HOME/.gitconfig\n\nI don't have a strong opinion on whether we should introduce such\nvariable (it seems the only use-case is the one which started this\nthread, and it is already solved without it, so ...).\n\n> But we do have such a variable: $HOME. The concept of $GIT_HOME was\n> proposed to provide a way to divert _just_ git to a different config\n> directory, something that would not be any easier with\n> $XDG_CONFIG_HOME.\n\nRight, but I don't see any use-case for this.\n\nThe use-case which started this thread was to have several physical\nusers using the same Unix account, with the desire that each physical\nuser should be able to use his own editor setups. In this case, you\nwant your editor and your other applications to follow the schema.\n\n> Anyway, as far as the future of git goes, even if we did want to switch\n> to $XDG_CONFIG_HOME, we could not do so suddenly without breaking\n> everybody's current setup. Which would mean any implementation of it\n> would have to handle both the current and the new proposed locations.\n> You can obviously just read from both, but there are a lot of open\n> questions, like \"which should take precedence?\" and \"what does git\n> config --global --edit do?\". I am not opposed to hearing a clever\n> proposal that handles all such issues, but I am not going to think too\n> hard about it myself. :)\n\nRight, the thing I had in mind was to use $XDG_CONFIG_HOME just like\n$GIT_HOME (i.e. use it if it's set), but doing so would suddenly break\nthe setup of people having already set $XDG_CONFIG_HOME, and having a\n$HOME/.gitconfig.\n\nWell, then, I don't know, maybe my proposal wasn't as clever as I\nthought ;-).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"130219","messageId":"4B2FA82B.3080305@drmicha.warpmail.net","threadId":"21986","inReplyTo":"vpqskb49tuq.fsf@bauges.imag.fr","subject":"Re: [PATCH] Introduce the GIT_HOME environment variable","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-12-21T16:54:03Z","receivedAt":"2009-12-21T16:54:03Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Matthieu Moy venit, vidit, dixit 21.12.2009 17:26:\n> Jeff King <peff@peff.net> writes:\n> \n>> Are we even close to having this sort of universal support for\n>> ~/.config?\n> \n> Definitely not universal as of now. Probably precisely because each\n> application thinks \"I'll take care of $XDG_CONFIG_HOME after others\n> do\" ;-).\n> \n>> Traditionally, the standard for Unix\n>> has been for config files to be $HOME/.something. You can argue that\n>> ~/.config is a better standard, but I don't think git is failing to\n>> use a standard; it is simply following a different one.\n> \n> I've probably been unclear about this. I'm not arguing about moving\n> away from $HOME/.gitconfig as the default (IOW, we're in agreement\n> here ;-) ). It's there, and the migration path would be much more\n> painfull than the benefit.\n> \n> What I'm saying is that _if_ we introduce a variable to point to an\n> alternate .gitconfig, then we should use something like\n> $XDG_CONFIG_HOME/git/config and not $GIT_HOME/.gitconfig\n> \n> I don't have a strong opinion on whether we should introduce such\n> variable (it seems the only use-case is the one which started this\n> thread, and it is already solved without it, so ...).\n> \n>> But we do have such a variable: $HOME. The concept of $GIT_HOME was\n>> proposed to provide a way to divert _just_ git to a different config\n>> directory, something that would not be any easier with\n>> $XDG_CONFIG_HOME.\n> \n> Right, but I don't see any use-case for this.\n> \n> The use-case which started this thread was to have several physical\n> users using the same Unix account, with the desire that each physical\n> user should be able to use his own editor setups. In this case, you\n> want your editor and your other applications to follow the schema.\n> \n>> Anyway, as far as the future of git goes, even if we did want to switch\n>> to $XDG_CONFIG_HOME, we could not do so suddenly without breaking\n>> everybody's current setup. Which would mean any implementation of it\n>> would have to handle both the current and the new proposed locations.\n>> You can obviously just read from both, but there are a lot of open\n>> questions, like \"which should take precedence?\" and \"what does git\n>> config --global --edit do?\". I am not opposed to hearing a clever\n>> proposal that handles all such issues, but I am not going to think too\n>> hard about it myself. :)\n> \n> Right, the thing I had in mind was to use $XDG_CONFIG_HOME just like\n> $GIT_HOME (i.e. use it if it's set), but doing so would suddenly break\n> the setup of people having already set $XDG_CONFIG_HOME, and having a\n> $HOME/.gitconfig.\n> \n> Well, then, I don't know, maybe my proposal wasn't as clever as I\n> thought ;-).\n\nWell, I'd say the usual approach would be \"use the first one found out\nof $XYZ/config and $HOME/.gitconfig in this order\", whether XYZ equals\n$GIT_HOME or $XDG_CONFIG_HOME/git or what not. And that applies both to\nreading as well writing the config. We should only merge config from\ndifferent types of sources (system/global/local), not from alternate\nlocations within the same type.\n\nThat way, nobody's setup gets broken, and having \"git_custom_home()\"\nfactorized out there is no real maintenance burden. I have no opinion\nabout the choice of XYZ.\n\nMichael\n"}]}