FEATURE REQUEST: Env override GIT_GLOBAL_CONFIG

FEATURE REQUEST: Env override GIT_GLOBAL_CONFIG

[Moe]

Hello list,

I'm looking for a way to read a custom config file in
addition to .git/config.

An env var along the lines of GIT_GLOBAL_CONFIG (and perhaps
GIT_SYSTEM_CONFIG) to override the default locations of
~/.gitconfig or $prefix/etc/gitconfig would be most
welcome here.

$GIT_CONFIG doesn't work for this purpose because when set
git will *only* read the referenced file and ignore the
repository settings.

$GIT_CONFIG_LOCAL wouldn't do either and has been
removed from git anyways.


Use-Case:
Multiple users sharing one unix account. Trying to inject the respective
git identity and other preferences without overwriting
the actual .gitconfig-file - because that doesn't work when multiple
users are logged in concurrently to the same unix-account.


Kind regards,
Moe

[PATCH] Introduce the GIT_CONFIG_EXTRA environment variable

[Miklos Vajna]

This is like GIT_CONFIG but it is not read instead of .git/config, but
in addtition to it.

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---

On Fri, Dec 18, 2009 at 11:54:32PM +0100, Moe <moe@signalbeam.net> wrote:
> $GIT_CONFIG doesn't work for this purpose because when set
> git will *only* read the referenced file and ignore the
> repository settings.

What about this?

 Documentation/git-config.txt |    3 +++
 builtin-config.c             |    7 ++++++-
 config.c                     |    9 ++++++++-
 t/t1300-repo-config.sh       |   16 ++++++++++++++++
 4 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index f68b198..668db3f 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -211,6 +211,9 @@ GIT_CONFIG::
 	Using the "--global" option forces this to ~/.gitconfig. Using the
 	"--system" option forces this to $(prefix)/etc/gitconfig.
 
+GIT_CONFIG_EXTRA::
+	Take the configuration from the given file in addition to .git/config.
+
 See also <<FILES>>.
 
 
diff --git a/builtin-config.c b/builtin-config.c
index a2d656e..4a702f6 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -142,7 +142,7 @@ static int get_value(const char *key_, const char *regex_)
 	int ret = -1;
 	char *tl;
 	char *global = NULL, *repo_config = NULL;
-	const char *system_wide = NULL, *local;
+	const char *system_wide = NULL, *local, *extra = NULL;
 
 	local = config_exclusive_filename;
 	if (!local) {
@@ -152,6 +152,7 @@ static int get_value(const char *key_, const char *regex_)
 			global = xstrdup(mkpath("%s/.gitconfig", home));
 		if (git_config_system())
 			system_wide = git_etc_gitconfig();
+		extra = getenv("GIT_CONFIG_EXTRA");
 	}
 
 	key = xstrdup(key_);
@@ -185,11 +186,15 @@ static int get_value(const char *key_, const char *regex_)
 		git_config_from_file(show_config, system_wide, NULL);
 	if (do_all && global)
 		git_config_from_file(show_config, global, NULL);
+	if (do_all && extra)
+		git_config_from_file(show_config, extra, NULL);
 	git_config_from_file(show_config, local, NULL);
 	if (!do_all && !seen && global)
 		git_config_from_file(show_config, global, NULL);
 	if (!do_all && !seen && system_wide)
 		git_config_from_file(show_config, system_wide, NULL);
+	if (!do_all && !seen && extra)
+		git_config_from_file(show_config, extra, NULL);
 
 	free(key);
 	if (regexp) {
diff --git a/config.c b/config.c
index 37385ce..cf816ed 100644
--- a/config.c
+++ b/config.c
@@ -700,7 +700,7 @@ int git_config(config_fn_t fn, void *data)
 {
 	int ret = 0, found = 0;
 	char *repo_config = NULL;
-	const char *home = NULL;
+	const char *home = NULL, *extra = NULL;
 
 	/* Setting $GIT_CONFIG makes git read _only_ the given config file. */
 	if (config_exclusive_filename)
@@ -727,6 +727,13 @@ int git_config(config_fn_t fn, void *data)
 		found += 1;
 	}
 	free(repo_config);
+
+	extra = getenv("GIT_CONFIG_EXTRA");
+	if (extra && !access(extra, R_OK)) {
+		ret += git_config_from_file(fn, extra, data);
+		found += 1;
+	}
+
 	if (found == 0)
 		return -1;
 	return ret;
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 83b7294..ed7fcb6 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -398,6 +398,22 @@ test_expect_success 'alternative GIT_CONFIG' 'cmp output expect'
 test_expect_success 'alternative GIT_CONFIG (--file)' \
 	'git config --file other-config -l > output && cmp output expect'
 
+cat > extra-config <<EOF
+[extra]
+	config = value
+EOF
+
+cat > expect << EOF
+c
+value
+EOF
+
+test_expect_success 'additional GIT_CONFIG_EXTRA' '
+	GIT_CONFIG_EXTRA=extra-config git config a.b > output &&
+	GIT_CONFIG_EXTRA=extra-config git config extra.config >> output &&
+	cmp output expect
+'
+
 GIT_CONFIG=other-config git config anwohner.park ausweis
 
 cat > expect << EOF
-- 
1.6.5.2

Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable

[Shawn O. Pearce]

Miklos Vajna <vmiklos@frugalware.org> wrote:
> This is like GIT_CONFIG but it is not read instead of .git/config, but
> in addtition to it.

What file does `git config --add` modify?  Should we be able to
modify the GIT_CONFIG_EXTRA file?

What order is GIT_CONFIG_EXTRA applied in relative to other files
that git config would also have read?

-- 
Shawn.

Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable

[Moe]

Shawn O. Pearce wrote:
> Miklos Vajna <vmiklos@frugalware.org> wrote:
>> This is like GIT_CONFIG but it is not read instead of .git/config, but
>> in addtition to it.
> 
> What file does `git config --add` modify?  Should we be able to
> modify the GIT_CONFIG_EXTRA file?

>From my use-case corner: Yes, this would basically be used
to divert ~/.gitconfig and should behave in all the same ways.

> What order is GIT_CONFIG_EXTRA applied in relative to other files
> that git config would also have read?

This is up to Miklos to answer but again from my use-case angle it would
make the most sense to read the usual config files first
and GIT_CONFIG_EXTRA last - that way the user config gets the
last word in terms of overriding global and repository defaults.

And btw, thanks for the fast action Miklos!


Kind regards,
Moe

Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable

[Junio C Hamano]

Miklos Vajna <vmiklos@frugalware.org> writes:

> This is like GIT_CONFIG but it is not read instead of .git/config, but
> in addtition to it.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> On Fri, Dec 18, 2009 at 11:54:32PM +0100, Moe <moe@signalbeam.net> wrote:
>> $GIT_CONFIG doesn't work for this purpose because when set
>> git will *only* read the referenced file and ignore the
>> repository settings.
>
> What about this?


The patch text itself may be fine, in the sense that it makes "we read
from three" to "we now read from four", but I am not impressed.

I find the original use case highly moronic.

For people to be sharing an account, hence $HOME, there must be a reason.
They want to (rather, the administrator wants them to) use a common shared
set of settings, so $HOME/.gitconfig should be shared among them, just
like $HOME/.emacs and $HOME/.login are, unless there is some strong reason
to treat .gitconfig any differently from all the other $HOME/.whatever
files.  But I don't think there wasn't any argument to defend that.

That makes the patch doubly suspect and throws it into "because we can",
not "because we should".

Wouldn't it be just a matter of giving different HOME after they log-in?

After all, Moe will be giving _some_ way to his users set different value
to GIT_CONFIG_EXTRA depending on who they really are, and that same
mechanism should be usable to set different HOME to them, no?

As $HOME/.gitconfig is relative to the value of that environment variable,
I don't see a reason for us to fall into this "three is not enough, but
when we add another, we are fine" attitude, which makes me suspect that
there is something fundamentally wrong there.

Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable

[Moe]

Junio C Hamano wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
> 
>> This is like GIT_CONFIG but it is not read instead of .git/config, but
>> in addtition to it.
>>
>> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
>> ---
>>
>> On Fri, Dec 18, 2009 at 11:54:32PM +0100, Moe <moe@signalbeam.net> wrote:
>>> $GIT_CONFIG doesn't work for this purpose because when set
>>> git will *only* read the referenced file and ignore the
>>> repository settings.
>> What about this?
> 
> 
> The patch text itself may be fine, in the sense that it makes "we read
> from three" to "we now read from four", but I am not impressed.
> 
> I find the original use case highly moronic.
>
> For people to be sharing an account, hence $HOME, there must be a reason.
> They want to (rather, the administrator wants them to) use a common shared
> set of settings, so $HOME/.gitconfig should be shared among them, just
> like $HOME/.emacs and $HOME/.login are, unless there is some strong reason
> to treat .gitconfig any differently from all the other $HOME/.whatever
> files.  But I don't think there wasn't any argument to defend that.

I'm not arguing to treat .gitconfig differently from other
dot-files, but to treat it differently from .git/config.

The former is user-specific, the latter is repository-specific.

For a contrived analogy: Imagine apache would ignore the contents
of .htaccess files when you start httpd with the "-f" switch to
load a different configuration file.

> That makes the patch doubly suspect and throws it into "because we can",
> not "because we should".
> 
> Wouldn't it be just a matter of giving different HOME after they log-in?
> 
> After all, Moe will be giving _some_ way to his users set different value
> to GIT_CONFIG_EXTRA depending on who they really are, and that same
> mechanism should be usable to set different HOME to them, no?

The individual users are identified by their ssh key. Ssh sets a
distinct environment variable for each, which in turn is used in
.bash_profile to read an additional user-profile.

Yes, we could overwrite $HOME but that would defeat the purpose.

The goal of this setup is to share almost all settings.
Overwriting $HOME would turn this upside down. Instead of diverting
the two bits that we want to customize (git identity and editor
preferences) we would then have to duplicate all other dot-files
for each virtual user - and probably watch out for unforeseen side-effects.

> As $HOME/.gitconfig is relative to the value of that environment variable,
> I don't see a reason for us to fall into this "three is not enough, but
> when we add another, we are fine" attitude, which makes me suspect that
> there is something fundamentally wrong there.

I understand the sentiment.

Without drifting into a discussion about the merit of shared
unix-accounts (they do make a lot of sense in some scenarios)
I hope this can still make it, considering the small size of
the patch and the .git/config vs ~/.gitconfig argument.


-- 
Kind regards, Moe

Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable

[Junio C Hamano]

Moe <moe@signalbeam.net> writes:

>> I find the original use case highly moronic.
>>
>> For people to be sharing an account, hence $HOME, there must be a reason.
>> They want to (rather, the administrator wants them to) use a common shared
>> set of settings, so $HOME/.gitconfig should be shared among them, just
>> like $HOME/.emacs and $HOME/.login are, unless there is some strong reason
>> to treat .gitconfig any differently from all the other $HOME/.whatever
>> files.  But I don't think there wasn't any argument to defend that.
>
> I'm not arguing to treat .gitconfig differently from other
> dot-files, but to treat it differently from .git/config.
>
> The former is user-specific, the latter is repository-specific.

That is something we already do, like everybody else.  $HOME/.emacs is
user specific, /etc/emacs.d/* are site-wide, and "Local Variables:..End:"
section is per-document.  Have you asked emacs guys (and vim folks) about
a change similar to the one on topic here?  This question is rhetoric and
you do not have to answer it.

>> Wouldn't it be just a matter of giving different HOME after they log-in?
>> 
>> After all, Moe will be giving _some_ way to his users set different value
>> to GIT_CONFIG_EXTRA depending on who they really are, and that same
>> mechanism should be usable to set different HOME to them, no?
>
> The individual users are identified by their ssh key. Ssh sets a
> distinct environment variable for each, which in turn is used in
> .bash_profile to read an additional user-profile.
>
> Yes, we could overwrite $HOME but that would defeat the purpose.
> The goal of this setup is to share almost all settings.

You haven't answered the crucial question, and repeating yourself is not
an explanation.  I've already said sharing the account is to share things,
you know I understand you want to _share_.  I asked why $HOME/.gitconfig
has to be treated differently from others like $HOME/.mailrc, $HOME/.gitk,
etc. that are shared.  You are not answering the question.

What makes $HOME/.gitconfig different from $HOME/.ssh/., $HOME/.vimrc, and
all the other things?  Why do you want to share all the other dot files,
most of which lack the support for you to do the "set-up" you have to do
in $HOME/.bashrc to switch based on something other than the UID (I would
call that a "set-up", not a "hack", because you have to do that
somewhere)?  Why do your users tolerate that they cannot have their own
private $HOME/.rpmmacros nor $HOME/.newsrc but it is not Ok that they have
to share $HOME/.gitconfig with others?

Knowing that is very important for us, as $HOME/.gitconfig will not stay
the only thing you would need to single out with future versions of git.

For example, we have discussed a support for $HOME/.git-excludes that sits
between $GIT_DIR/info/exclude and the file pointed at by core.excludesfile
configuration variable.  Should it be shared, or separated?  Why?

I do not want to count on you, who I have never seen on this list before,
being around to ask if such a change would break your use case when the
day comes.  If we do not know the _criteria_ you are using, the reason why
you want to single out $HOME/.gitconfig when it is Ok for your users to
share $HOME/.vimrc, we will not be able to make good design decisions to
support this "shared account" configuration [*1*].  Will we introduce
GIT_EXCLUDE_EXTRA at the time like Miklos added GIT_CONFIG_EXTRA?  Where
does it end?

> I hope this can still make it, considering the small size of
> the patch and the .git/config vs ~/.gitconfig argument.

That is not an argument at all.  We handle .git/config vs $HOME/.gitconfig
just fine; see above.

One plausible answer you could have given is that your users do not have
an account in the usual sense of the word at all, and the _only_ thing
they can do with your system is to run git and nothing else.  IOW they
have no business with even having $HOME/.vimrc or $HOME/.rhosts, so these
other dotfiles do not matter at all.  That makes $HOME/.gitconfig special.

A possible solution might be for us to honor $GIT_HOME that is favoured
over $HOME, just like $GIT_EDITOR overrides $EDITOR.  That allows us to
extend the notion more naturally in the future.  For example, when we
start reading from $HOME/.git-excludes, if the GIT_HOME environment is
set, we would instead read from $GIT_HOME/.git-excludes.  That would be a
much cleaner solution than Miklos's patch [*2*].

But you have given us too little for us to be able to judge what the best
longer-term course of action is.  How could you even _hope_ it can "make
it"?


[Footnote]

*1* Of course, before doing so, we need to decide if this "shared account"
configuration makes sense or not to begin with, but you haven't given us
enough to work with to even decide that.

*2* I am not criticizing Miklos's patch in particular.  The patch was done
in the same void without any usable information from you what you really
needed, so the lack of provision for future we can see in the patch is not
Miklos's fault.  Also he is not the git maintainer and is not used to
worry about the future like I do.

Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable

[Moe]

Junio C Hamano wrote:
> Moe <moe@signalbeam.net> writes:
> 
>>> I find the original use case highly moronic.
>>>
>>> For people to be sharing an account, hence $HOME, there must be a reason.
>>> They want to (rather, the administrator wants them to) use a common shared
>>> set of settings, so $HOME/.gitconfig should be shared among them, just
>>> like $HOME/.emacs and $HOME/.login are, unless there is some strong reason
>>> to treat .gitconfig any differently from all the other $HOME/.whatever
>>> files.  But I don't think there wasn't any argument to defend that.
>> I'm not arguing to treat .gitconfig differently from other
>> dot-files, but to treat it differently from .git/config.
>>
>> The former is user-specific, the latter is repository-specific.
> 
> That is something we already do, like everybody else.  $HOME/.emacs is
> user specific, /etc/emacs.d/* are site-wide, and "Local Variables:..End:"
> section is per-document.  Have you asked emacs guys (and vim folks) about
> a change similar to the one on topic here?  This question is rhetoric and
> you do not have to answer it.
> 
>>> Wouldn't it be just a matter of giving different HOME after they log-in?
>>>
>>> After all, Moe will be giving _some_ way to his users set different value
>>> to GIT_CONFIG_EXTRA depending on who they really are, and that same
>>> mechanism should be usable to set different HOME to them, no?
>> The individual users are identified by their ssh key. Ssh sets a
>> distinct environment variable for each, which in turn is used in
>> .bash_profile to read an additional user-profile.
>>
>> Yes, we could overwrite $HOME but that would defeat the purpose.
>> The goal of this setup is to share almost all settings.
> 
> You haven't answered the crucial question, and repeating yourself is not
> an explanation.  I've already said sharing the account is to share things,
> you know I understand you want to _share_.  I asked why $HOME/.gitconfig
> has to be treated differently from others like $HOME/.mailrc, $HOME/.gitk,
> etc. that are shared.  You are not answering the question.

I refrained from delving deeper into our particular use-case at first,
due to the verbosity and to avoid a potential "git wasn't meant for
this" knockout. But it seems we're over this, so see below.

> What makes $HOME/.gitconfig different from $HOME/.ssh/., $HOME/.vimrc, and
> all the other things?  Why do you want to share all the other dot files,
> most of which lack the support for you to do the "set-up" you have to do
> in $HOME/.bashrc to switch based on something other than the UID (I would
> call that a "set-up", not a "hack", because you have to do that
> somewhere)?  Why do your users tolerate that they cannot have their own
> private $HOME/.rpmmacros nor $HOME/.newsrc but it is not Ok that they have
> to share $HOME/.gitconfig with others?
>
> Knowing that is very important for us, as $HOME/.gitconfig will not stay
> the only thing you would need to single out with future versions of git.
> 
> For example, we have discussed a support for $HOME/.git-excludes that sits
> between $GIT_DIR/info/exclude and the file pointed at by core.excludesfile
> configuration variable.  Should it be shared, or separated?  Why?
> 
> I do not want to count on you, who I have never seen on this list before,
> being around to ask if such a change would break your use case when the
> day comes.  If we do not know the _criteria_ you are using, the reason why
> you want to single out $HOME/.gitconfig when it is Ok for your users to
> share $HOME/.vimrc, we will not be able to make good design decisions to
> support this "shared account" configuration [*1*].  Will we introduce
> GIT_EXCLUDE_EXTRA at the time like Miklos added GIT_CONFIG_EXTRA?  Where
> does it end?
> 
>> I hope this can still make it, considering the small size of
>> the patch and the .git/config vs ~/.gitconfig argument.
> 
> That is not an argument at all.  We handle .git/config vs $HOME/.gitconfig
> just fine; see above.
> 
> One plausible answer you could have given is that your users do not have
> an account in the usual sense of the word at all, and the _only_ thing
> they can do with your system is to run git and nothing else.  IOW they
> have no business with even having $HOME/.vimrc or $HOME/.rhosts, so these
> other dotfiles do not matter at all.  That makes $HOME/.gitconfig special.

Yes, that's pretty close. What we do is, we put our entire runtime
environment [for a web application] under a dedicated user and under
version control. This is a very comfortable way to maintain an
identical environment across the board, we even deploy this way
to our production servers by the means of a git pull on a
dedicated branch.

In practice our developers will su or ssh to this user to get working
and generally they need only a very small set of divertions from the
common configuration - such as their personal git identity and their
preferred editor settings.

One may argue that a bunch of host-specific symlinks could achieve a
similar effect - and that would be correct - but having literally
everything under version control yields certain advantages that we
wouldn't want to miss. Such as any developer being able to ssh into
the shared user on any host and being right at home (including
properly attributed git commits) without further twiddling.
(that usually comes into play when ssh'ing into a production host,
 performing a hotfix and feeding it back)

This all may seem esoteric or even moronic to you. All I can say is
that it's been working extraordinary well for us over the past 2 years,
despite the minor git inconvenience.

> A possible solution might be for us to honor $GIT_HOME that is favoured
> over $HOME, just like $GIT_EDITOR overrides $EDITOR.  That allows us to
> extend the notion more naturally in the future.  For example, when we
> start reading from $HOME/.git-excludes, if the GIT_HOME environment is
> set, we would instead read from $GIT_HOME/.git-excludes.  That would be a
> much cleaner solution than Miklos's patch [*2*].

Sounds like that would serve our case just as well
and yes, probably much cleaner in the long run.

> But you have given us too little for us to be able to judge what the best
> longer-term course of action is.  How could you even _hope_ it can "make
> it"?

Well, sorry for being so brief initially. Being not as involved with git
development I based my request on what I figured could be a
sane generalization of our particular problem.

Also I don't mean to blow this out of proportion; it's a minor,
mostly cosmetic inconvenience for us and we can stick to our workarounds
or Miklos' patch if a mainline change shakes
things up too much.

Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable

[Johannes Schindelin]

Hi,

On Sat, 19 Dec 2009, Moe wrote:

> What we do is, we put our entire runtime environment [for a web 
> application] under a dedicated user and under version control. This is a 
> very comfortable way to maintain an identical environment across the 
> board, we even deploy this way to our production servers by the means of 
> a git pull on a dedicated branch.

Just ignoring the fact that you version control a version controlled 
directory (including the repository), which is inefficient, and even 
further ignoring the fact that you open the door for concurrent -- 
incompatible -- modifications, if all you want to do is:

> In practice our developers will su or ssh to this user to get working 
> and generally they need only a very small set of divertions from the 
> common configuration - such as their personal git identity and their 
> preferred editor settings.

... then I suggest reading up on GIT_EDITOR, GIT_AUTHOR_IDENT and 
GIT_COMMITTER_IDENT, and leaving the $HOME/.gitconfig alone.

Ciao,
Dscho

Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable

[Moe]

Johannes Schindelin wrote:
> Hi,
> 
> On Sat, 19 Dec 2009, Moe wrote:
> 
>> What we do is, we put our entire runtime environment [for a web 
>> application] under a dedicated user and under version control. This is a 
>> very comfortable way to maintain an identical environment across the 
>> board, we even deploy this way to our production servers by the means of 
>> a git pull on a dedicated branch.
> 
> Just ignoring the fact that you version control a version controlled 
> directory (including the repository), which is inefficient, and even 
> further ignoring the fact that you open the door for concurrent -- 
> incompatible -- modifications, if all you want to do is:

Neither is true.

>> In practice our developers will su or ssh to this user to get working 
>> and generally they need only a very small set of divertions from the 
>> common configuration - such as their personal git identity and their 
>> preferred editor settings.
> 
> ... then I suggest reading up on GIT_EDITOR, GIT_AUTHOR_IDENT and 
> GIT_COMMITTER_IDENT, and leaving the $HOME/.gitconfig alone.

Thanks, that solved my problem.
Seems I started by asking the wrong question.

Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On Fri, Dec 18, 2009 at 06:09:47PM -0800, "Shawn O. Pearce" <spearce@spearce.org> wrote:
> What file does `git config --add` modify?  Should we be able to
> modify the GIT_CONFIG_EXTRA file?

git config --add will still write .git/config (or $GIT_CONFIG) as
before. At the moment there is no way to modify a GIT_CONFIG_EXTRA file
using git-config.

> What order is GIT_CONFIG_EXTRA applied in relative to other files
> that git config would also have read?

The config file from GIT_CONFIG_EXTRA is the last one that is read.

Adding the above feature and documenting the later answer could be done
in a second version of such a patch, but as far as I see it's no good
doing so because then patch solves a non-exsiting problem. ;-)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable

[Nanako Shiraishi]

Quoting Moe <moe@signalbeam.net>

> In practice our developers will su or ssh to this user to get working
> and generally they need only a very small set of divertions from the
> common configuration - such as their personal git identity and their
> preferred editor settings.

Do "preferred editor settings" mean $HOME/.vim that was one of 
Junio's examples? How do you handle it?

It sounds like you are only interested in user.name and 
user.email, and you don't need to override $HOME/.gitconfig as 
a whole.  Because you already have a section in $HOME/.bashrc 
that does different things based on the user's SSH key, you 
may want to set variables GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL 
in there without doing anything else if that is the case.

> One may argue that a bunch of host-specific symlinks could achieve a
> similar effect - and that would be correct - but having literally
> everything under version control yields certain advantages that we
> wouldn't want to miss.

Sorry, but I don't understand. What do symlinks have to do 
with keeping everything under version control? git can track 
symbolic links just fine, if that is what is troubling you.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

[PATCH] Introduce the GIT_HOME environment variable

[Miklos Vajna]

Honor $GIT_HOME that is favoured over $HOME, just like $GIT_EDITOR
overrides $EDITOR.  That allows us to extend the notion more naturally
in the future.  For example, when we start reading from
$HOME/.gitconfig, if the GIT_HOME environment is set, we would instead
read from $GIT_HOME/.gitconfig.

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---

On Fri, Dec 18, 2009 at 09:55:07PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> A possible solution might be for us to honor $GIT_HOME that is favoured
> over $HOME, just like $GIT_EDITOR overrides $EDITOR.  That allows us to
> extend the notion more naturally in the future.  For example, when we
> start reading from $HOME/.git-excludes, if the GIT_HOME environment is
> set, we would instead read from $GIT_HOME/.git-excludes.  That would be a
> much cleaner solution than Miklos's patch [*2*].

Something like this?

I've stolen most of the commit message from your mail. ;-)

 Documentation/config.txt |   14 ++++++++++----
 builtin-config.c         |    8 ++++++--
 config.c                 |    4 +++-
 path.c                   |    4 +++-
 t/t1300-repo-config.sh   |    7 +++++++
 5 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index a1e36d7..09cbc71 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -8,6 +8,10 @@ is used to store the configuration for that repository, and
 fallback values for the `.git/config` file. The file `/etc/gitconfig`
 can be used to store a system-wide default configuration.
 
+In case you want to store your per-user configuration in a directory
+different to `$HOME`, you can use the `$GIT_HOME` environment variable
+which has preference.
+
 The configuration variables are used by both the git plumbing
 and the porcelains. The variables are divided into sections, wherein
 the fully qualified variable name of the variable itself is the last
@@ -406,8 +410,9 @@ core.excludesfile::
 	In addition to '.gitignore' (per-directory) and
 	'.git/info/exclude', git looks into this file for patterns
 	of files which are not meant to be tracked.  "{tilde}/" is expanded
-	to the value of `$HOME` and "{tilde}user/" to the specified user's
-	home directory.  See linkgit:gitignore[5].
+	to the value of `$GIT_HOME` (or `$HOME` if `$GIT_HOME` is not
+	set) and "{tilde}user/" to the specified user's home directory.  See
+	linkgit:gitignore[5].
 
 core.editor::
 	Commands such as `commit` and `tag` that lets you edit
@@ -707,8 +712,9 @@ color.ui::
 
 commit.template::
 	Specify a file to use as the template for new commit messages.
-	"{tilde}/" is expanded to the value of `$HOME` and "{tilde}user/" to the
-	specified user's home directory.
+	"{tilde}/" is expanded to the value of `$GIT_HOME` (or `$HOME`
+	if `$GIT_HOME` is not set) and "{tilde}user/" to the specified user's
+	home directory.
 
 diff.autorefreshindex::
 	When using 'git-diff' to compare with work tree
diff --git a/builtin-config.c b/builtin-config.c
index a2d656e..da9ebd4 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -146,7 +146,9 @@ static int get_value(const char *key_, const char *regex_)
 
 	local = config_exclusive_filename;
 	if (!local) {
-		const char *home = getenv("HOME");
+		const char *home = getenv("GIT_HOME");
+		if (!home)
+			home = getenv("HOME");
 		local = repo_config = git_pathdup("config");
 		if (git_config_global() && home)
 			global = xstrdup(mkpath("%s/.gitconfig", home));
@@ -326,7 +328,9 @@ int cmd_config(int argc, const char **argv, const char *unused_prefix)
 	}
 
 	if (use_global_config) {
-		char *home = getenv("HOME");
+		char *home = getenv("GIT_HOME");
+		if (!home)
+			home = getenv("HOME");
 		if (home) {
 			char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
 			config_exclusive_filename = user_config;
diff --git a/config.c b/config.c
index 37385ce..7e2ccdb 100644
--- a/config.c
+++ b/config.c
@@ -711,7 +711,9 @@ int git_config(config_fn_t fn, void *data)
 		found += 1;
 	}
 
-	home = getenv("HOME");
+	home = getenv("GIT_HOME");
+	if (!home)
+		home = getenv("HOME");
 	if (git_config_global() && home) {
 		char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
 		if (!access(user_config, R_OK)) {
diff --git a/path.c b/path.c
index 2ec950b..b42a1b6 100644
--- a/path.c
+++ b/path.c
@@ -236,7 +236,9 @@ char *expand_user_path(const char *path)
 		const char *username = path + 1;
 		size_t username_len = first_slash - username;
 		if (username_len == 0) {
-			const char *home = getenv("HOME");
+			const char *home = getenv("GIT_HOME");
+			if (!home)
+				home = getenv("HOME");
 			strbuf_add(&user_path, home, strlen(home));
 		} else {
 			struct passwd *pw = getpw_str(username, username_len);
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 83b7294..d9818ab 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -18,6 +18,13 @@ EOF
 
 test_expect_success 'initial' 'cmp .git/config expect'
 
+test_expect_success 'GIT_HOME' '
+	GIT_HOME="`pwd`" &&
+	export GIT_HOME &&
+	git config --global core.penguin "little blue" &&
+	cmp "$GIT_HOME"/.gitconfig expect
+'
+
 git config Core.Movie BadPhysics
 
 cat > expect << EOF
-- 
1.6.5.2

Re: [PATCH] Introduce the GIT_HOME environment variable

[Michael J Gruber]

Miklos Vajna venit, vidit, dixit 19.12.2009 16:30:
> Honor $GIT_HOME that is favoured over $HOME, just like $GIT_EDITOR
> overrides $EDITOR.  That allows us to extend the notion more naturally
> in the future.  For example, when we start reading from
> $HOME/.gitconfig, if the GIT_HOME environment is set, we would instead
> read from $GIT_HOME/.gitconfig.
> 
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
> 
> On Fri, Dec 18, 2009 at 09:55:07PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
>> A possible solution might be for us to honor $GIT_HOME that is favoured
>> over $HOME, just like $GIT_EDITOR overrides $EDITOR.  That allows us to
>> extend the notion more naturally in the future.  For example, when we
>> start reading from $HOME/.git-excludes, if the GIT_HOME environment is
>> set, we would instead read from $GIT_HOME/.git-excludes.  That would be a
>> much cleaner solution than Miklos's patch [*2*].
> 
> Something like this?
> 
> I've stolen most of the commit message from your mail. ;-)

Yes, but it makes less sense this way... Junio wrote "when we start
reading" because we don't do that yet. But we read ~/.gitconfig, of
course, so "when we start reading" sounds funny here.

> 
>  Documentation/config.txt |   14 ++++++++++----
>  builtin-config.c         |    8 ++++++--
>  config.c                 |    4 +++-
>  path.c                   |    4 +++-
>  t/t1300-repo-config.sh   |    7 +++++++
>  5 files changed, 29 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index a1e36d7..09cbc71 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -8,6 +8,10 @@ is used to store the configuration for that repository, and
>  fallback values for the `.git/config` file. The file `/etc/gitconfig`
>  can be used to store a system-wide default configuration.
>  
> +In case you want to store your per-user configuration in a directory
> +different to `$HOME`, you can use the `$GIT_HOME` environment variable

"different from"

> +which has preference.
> +
>  The configuration variables are used by both the git plumbing
>  and the porcelains. The variables are divided into sections, wherein
>  the fully qualified variable name of the variable itself is the last
> @@ -406,8 +410,9 @@ core.excludesfile::
>  	In addition to '.gitignore' (per-directory) and
>  	'.git/info/exclude', git looks into this file for patterns
>  	of files which are not meant to be tracked.  "{tilde}/" is expanded
> -	to the value of `$HOME` and "{tilde}user/" to the specified user's
> -	home directory.  See linkgit:gitignore[5].
> +	to the value of `$GIT_HOME` (or `$HOME` if `$GIT_HOME` is not
> +	set) and "{tilde}user/" to the specified user's home directory.  See
> +	linkgit:gitignore[5].
>  
>  core.editor::
>  	Commands such as `commit` and `tag` that lets you edit
> @@ -707,8 +712,9 @@ color.ui::
>  
>  commit.template::
>  	Specify a file to use as the template for new commit messages.
> -	"{tilde}/" is expanded to the value of `$HOME` and "{tilde}user/" to the
> -	specified user's home directory.
> +	"{tilde}/" is expanded to the value of `$GIT_HOME` (or `$HOME`
> +	if `$GIT_HOME` is not set) and "{tilde}user/" to the specified user's
> +	home directory.
>  
>  diff.autorefreshindex::
>  	When using 'git-diff' to compare with work tree
> diff --git a/builtin-config.c b/builtin-config.c
> index a2d656e..da9ebd4 100644
> --- a/builtin-config.c
> +++ b/builtin-config.c
> @@ -146,7 +146,9 @@ static int get_value(const char *key_, const char *regex_)
>  
>  	local = config_exclusive_filename;
>  	if (!local) {
> -		const char *home = getenv("HOME");
> +		const char *home = getenv("GIT_HOME");
> +		if (!home)
> +			home = getenv("HOME");
>  		local = repo_config = git_pathdup("config");
>  		if (git_config_global() && home)
>  			global = xstrdup(mkpath("%s/.gitconfig", home));
> @@ -326,7 +328,9 @@ int cmd_config(int argc, const char **argv, const char *unused_prefix)
>  	}
>  
>  	if (use_global_config) {
> -		char *home = getenv("HOME");
> +		char *home = getenv("GIT_HOME");
> +		if (!home)
> +			home = getenv("HOME");
>  		if (home) {
>  			char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
>  			config_exclusive_filename = user_config;
> diff --git a/config.c b/config.c
> index 37385ce..7e2ccdb 100644
> --- a/config.c
> +++ b/config.c
> @@ -711,7 +711,9 @@ int git_config(config_fn_t fn, void *data)
>  		found += 1;
>  	}
>  
> -	home = getenv("HOME");
> +	home = getenv("GIT_HOME");
> +	if (!home)
> +		home = getenv("HOME");
>  	if (git_config_global() && home) {
>  		char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
>  		if (!access(user_config, R_OK)) {
> diff --git a/path.c b/path.c
> index 2ec950b..b42a1b6 100644
> --- a/path.c
> +++ b/path.c
> @@ -236,7 +236,9 @@ char *expand_user_path(const char *path)
>  		const char *username = path + 1;
>  		size_t username_len = first_slash - username;
>  		if (username_len == 0) {
> -			const char *home = getenv("HOME");
> +			const char *home = getenv("GIT_HOME");
> +			if (!home)
> +				home = getenv("HOME");
>  			strbuf_add(&user_path, home, strlen(home));
>  		} else {
>  			struct passwd *pw = getpw_str(username, username_len);
> diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
> index 83b7294..d9818ab 100755
> --- a/t/t1300-repo-config.sh
> +++ b/t/t1300-repo-config.sh
> @@ -18,6 +18,13 @@ EOF
>  
>  test_expect_success 'initial' 'cmp .git/config expect'
>  
> +test_expect_success 'GIT_HOME' '
> +	GIT_HOME="`pwd`" &&
> +	export GIT_HOME &&
> +	git config --global core.penguin "little blue" &&
> +	cmp "$GIT_HOME"/.gitconfig expect
> +'
> +
>  git config Core.Movie BadPhysics
>  
>  cat > expect << EOF

[PATCH] Introduce the GIT_HOME environment variable

[Miklos Vajna]

Honor $GIT_HOME that is favoured over $HOME, just like $GIT_EDITOR
overrides $EDITOR.  That allows us to extend the notion more naturally
in the future.  For example, when we read from $HOME/.gitconfig, if the
GIT_HOME environment is set, we instead read from $GIT_HOME/.gitconfig.

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---

On Sat, Dec 19, 2009 at 05:18:25PM +0100, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Yes, but it makes less sense this way... Junio wrote "when we start
> reading" because we don't do that yet. But we read ~/.gitconfig, of
> course, so "when we start reading" sounds funny here.
>
> (...)
>
> "different from"

Fixed both, thanks.

 Documentation/config.txt |   14 ++++++++++----
 builtin-config.c         |    8 ++++++--
 config.c                 |    4 +++-
 path.c                   |    4 +++-
 t/t1300-repo-config.sh   |    7 +++++++
 5 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index a1e36d7..09cbc71 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -8,6 +8,10 @@ is used to store the configuration for that repository, and
 fallback values for the `.git/config` file. The file `/etc/gitconfig`
 can be used to store a system-wide default configuration.
 
+In case you want to store your per-user configuration in a directory
+different from `$HOME`, you can use the `$GIT_HOME` environment variable
+which has preference.
+
 The configuration variables are used by both the git plumbing
 and the porcelains. The variables are divided into sections, wherein
 the fully qualified variable name of the variable itself is the last
@@ -406,8 +410,9 @@ core.excludesfile::
 	In addition to '.gitignore' (per-directory) and
 	'.git/info/exclude', git looks into this file for patterns
 	of files which are not meant to be tracked.  "{tilde}/" is expanded
-	to the value of `$HOME` and "{tilde}user/" to the specified user's
-	home directory.  See linkgit:gitignore[5].
+	to the value of `$GIT_HOME` (or `$HOME` if `$GIT_HOME` is not
+	set) and "{tilde}user/" to the specified user's home directory.  See
+	linkgit:gitignore[5].
 
 core.editor::
 	Commands such as `commit` and `tag` that lets you edit
@@ -707,8 +712,9 @@ color.ui::
 
 commit.template::
 	Specify a file to use as the template for new commit messages.
-	"{tilde}/" is expanded to the value of `$HOME` and "{tilde}user/" to the
-	specified user's home directory.
+	"{tilde}/" is expanded to the value of `$GIT_HOME` (or `$HOME`
+	if `$GIT_HOME` is not set) and "{tilde}user/" to the specified user's
+	home directory.
 
 diff.autorefreshindex::
 	When using 'git-diff' to compare with work tree
diff --git a/builtin-config.c b/builtin-config.c
index a2d656e..da9ebd4 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -146,7 +146,9 @@ static int get_value(const char *key_, const char *regex_)
 
 	local = config_exclusive_filename;
 	if (!local) {
-		const char *home = getenv("HOME");
+		const char *home = getenv("GIT_HOME");
+		if (!home)
+			home = getenv("HOME");
 		local = repo_config = git_pathdup("config");
 		if (git_config_global() && home)
 			global = xstrdup(mkpath("%s/.gitconfig", home));
@@ -326,7 +328,9 @@ int cmd_config(int argc, const char **argv, const char *unused_prefix)
 	}
 
 	if (use_global_config) {
-		char *home = getenv("HOME");
+		char *home = getenv("GIT_HOME");
+		if (!home)
+			home = getenv("HOME");
 		if (home) {
 			char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
 			config_exclusive_filename = user_config;
diff --git a/config.c b/config.c
index 37385ce..7e2ccdb 100644
--- a/config.c
+++ b/config.c
@@ -711,7 +711,9 @@ int git_config(config_fn_t fn, void *data)
 		found += 1;
 	}
 
-	home = getenv("HOME");
+	home = getenv("GIT_HOME");
+	if (!home)
+		home = getenv("HOME");
 	if (git_config_global() && home) {
 		char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
 		if (!access(user_config, R_OK)) {
diff --git a/path.c b/path.c
index 2ec950b..b42a1b6 100644
--- a/path.c
+++ b/path.c
@@ -236,7 +236,9 @@ char *expand_user_path(const char *path)
 		const char *username = path + 1;
 		size_t username_len = first_slash - username;
 		if (username_len == 0) {
-			const char *home = getenv("HOME");
+			const char *home = getenv("GIT_HOME");
+			if (!home)
+				home = getenv("HOME");
 			strbuf_add(&user_path, home, strlen(home));
 		} else {
 			struct passwd *pw = getpw_str(username, username_len);
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 83b7294..d9818ab 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -18,6 +18,13 @@ EOF
 
 test_expect_success 'initial' 'cmp .git/config expect'
 
+test_expect_success 'GIT_HOME' '
+	GIT_HOME="`pwd`" &&
+	export GIT_HOME &&
+	git config --global core.penguin "little blue" &&
+	cmp "$GIT_HOME"/.gitconfig expect
+'
+
 git config Core.Movie BadPhysics
 
 cat > expect << EOF
-- 
1.6.5.2

Re: [PATCH] Introduce the GIT_HOME environment variable

[Matthieu Moy]

Miklos Vajna <vmiklos@frugalware.org> writes:

> Honor $GIT_HOME that is favoured over $HOME,

I'd personally prefer obeying $XDG_CONFIG_HOME, and read
$XDG_CONFIG_HOME/git/config (defaulting to $HOME/.config/git/config)
or something like this :

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

cd ~/.config
ls

to see a user's configuration for many applications at a time, and

cd ~/.config
git init

to version-control it.

* It avoids hidden files. With $GIT_CONFIG, a user doing

cd $GIT_HOME
ls

sees nothing. I understand why $HOME/something config files are
hidden, but a config file stored in a separate directory shouldn't be
hidden (just like $GIT_DIR/config is not hidden).

> -		const char *home = getenv("HOME");
> +		const char *home = getenv("GIT_HOME");
> +		if (!home)
> +			home = getenv("HOME");

If you go this way, why not define

const char *getenv_home()
{
	const char *home = getenv("GIT_HOME");
	if (!home)
		home = getenv("HOME");
	return home;
}

?

(probably in git-compat-util.h)

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH] Introduce the GIT_HOME environment variable

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> 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").  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,  And I personally don't care very much about that
second "It's really nice to be able to" point.

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.

Re: [PATCH] Introduce the GIT_HOME environment variable

[Junio C Hamano]

Miklos Vajna <vmiklos@frugalware.org> writes:

> diff --git a/builtin-config.c b/builtin-config.c
> index a2d656e..da9ebd4 100644
> --- a/builtin-config.c
> +++ b/builtin-config.c
> @@ -146,7 +146,9 @@ static int get_value(const char *key_, const char *regex_)
>  
>  	local = config_exclusive_filename;
>  	if (!local) {
> -		const char *home = getenv("HOME");
> +		const char *home = getenv("GIT_HOME");
> +		if (!home)
> +			home = getenv("HOME");

If you introduce a helper like this:

	const char *git_custom_home(void)
        {
        	const char *val = getenv("GIT_HOME");
                if (!val)
                	val = getenv("HOME");
		return val;
	}

then a mechanical s/getenv("GIT_HOME")/gitcustom_home()/; will make the
resulting code a lot simpler and a new callsite somebody may add in the
future would not have to duplicate three lines.

But I sense that Moe is retracting his claim that the unmodified git
doesn't do what he needs to do, after Dscho suggested to use more specific
environment variables to the task at hand?

[PATCH] Introduce the GIT_HOME environment variable

[Miklos Vajna]

Honor $GIT_HOME that is favoured over $HOME, just like $GIT_EDITOR
overrides $EDITOR.  That allows us to extend the notion more naturally
in the future.  For example, when we start reading from
$HOME/.gitconfig, if the GIT_HOME environment is set, we would instead
read from $GIT_HOME/.gitconfig.

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---

On Sat, Dec 19, 2009 at 11:21:57AM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> then a mechanical s/getenv("GIT_HOME")/gitcustom_home()/; will make the
> resulting code a lot simpler and a new callsite somebody may add in the
> future would not have to duplicate three lines.

Done.

> But I sense that Moe is retracting his claim that the unmodified git
> doesn't do what he needs to do, after Dscho suggested to use more specific
> environment variables to the task at hand?

I think Moe's problem is now solved by Dscho's suggestion, but this
patch helps other users where the user-specific setting may contain
other settings like diff.color (when $HOME is the same but GIT_HOME is
set based on ssh keys).

 Documentation/config.txt |   14 ++++++++++----
 builtin-config.c         |    4 ++--
 config.c                 |    2 +-
 git-compat-util.h        |    2 ++
 path.c                   |    2 +-
 t/t1300-repo-config.sh   |    7 +++++++
 wrapper.c                |    7 +++++++
 7 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index a1e36d7..09cbc71 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -8,6 +8,10 @@ is used to store the configuration for that repository, and
 fallback values for the `.git/config` file. The file `/etc/gitconfig`
 can be used to store a system-wide default configuration.
 
+In case you want to store your per-user configuration in a directory
+different to `$HOME`, you can use the `$GIT_HOME` environment variable
+which has preference.
+
 The configuration variables are used by both the git plumbing
 and the porcelains. The variables are divided into sections, wherein
 the fully qualified variable name of the variable itself is the last
@@ -406,8 +410,9 @@ core.excludesfile::
 	In addition to '.gitignore' (per-directory) and
 	'.git/info/exclude', git looks into this file for patterns
 	of files which are not meant to be tracked.  "{tilde}/" is expanded
-	to the value of `$HOME` and "{tilde}user/" to the specified user's
-	home directory.  See linkgit:gitignore[5].
+	to the value of `$GIT_HOME` (or `$HOME` if `$GIT_HOME` is not
+	set) and "{tilde}user/" to the specified user's home directory.  See
+	linkgit:gitignore[5].
 
 core.editor::
 	Commands such as `commit` and `tag` that lets you edit
@@ -707,8 +712,9 @@ color.ui::
 
 commit.template::
 	Specify a file to use as the template for new commit messages.
-	"{tilde}/" is expanded to the value of `$HOME` and "{tilde}user/" to the
-	specified user's home directory.
+	"{tilde}/" is expanded to the value of `$GIT_HOME` (or `$HOME`
+	if `$GIT_HOME` is not set) and "{tilde}user/" to the specified user's
+	home directory.
 
 diff.autorefreshindex::
 	When using 'git-diff' to compare with work tree
diff --git a/builtin-config.c b/builtin-config.c
index a2d656e..97284c6 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -146,7 +146,7 @@ static int get_value(const char *key_, const char *regex_)
 
 	local = config_exclusive_filename;
 	if (!local) {
-		const char *home = getenv("HOME");
+		const char *home = git_custom_home();
 		local = repo_config = git_pathdup("config");
 		if (git_config_global() && home)
 			global = xstrdup(mkpath("%s/.gitconfig", home));
@@ -326,7 +326,7 @@ int cmd_config(int argc, const char **argv, const char *unused_prefix)
 	}
 
 	if (use_global_config) {
-		char *home = getenv("HOME");
+		const char *home = git_custom_home();
 		if (home) {
 			char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
 			config_exclusive_filename = user_config;
diff --git a/config.c b/config.c
index 37385ce..cb2add8 100644
--- a/config.c
+++ b/config.c
@@ -711,7 +711,7 @@ int git_config(config_fn_t fn, void *data)
 		found += 1;
 	}
 
-	home = getenv("HOME");
+	home = git_custom_home();
 	if (git_config_global() && home) {
 		char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
 		if (!access(user_config, R_OK)) {
diff --git a/git-compat-util.h b/git-compat-util.h
index 5c59687..9f345da 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -465,4 +465,6 @@ void git_qsort(void *base, size_t nmemb, size_t size,
  */
 int unlink_or_warn(const char *path);
 
+const char *git_custom_home(void);
+
 #endif
diff --git a/path.c b/path.c
index 2ec950b..6038a95 100644
--- a/path.c
+++ b/path.c
@@ -236,7 +236,7 @@ char *expand_user_path(const char *path)
 		const char *username = path + 1;
 		size_t username_len = first_slash - username;
 		if (username_len == 0) {
-			const char *home = getenv("HOME");
+			const char *home = git_custom_home();
 			strbuf_add(&user_path, home, strlen(home));
 		} else {
 			struct passwd *pw = getpw_str(username, username_len);
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 83b7294..d9818ab 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -18,6 +18,13 @@ EOF
 
 test_expect_success 'initial' 'cmp .git/config expect'
 
+test_expect_success 'GIT_HOME' '
+	GIT_HOME="`pwd`" &&
+	export GIT_HOME &&
+	git config --global core.penguin "little blue" &&
+	cmp "$GIT_HOME"/.gitconfig expect
+'
+
 git config Core.Movie BadPhysics
 
 cat > expect << EOF
diff --git a/wrapper.c b/wrapper.c
index c9be140..b7f6649 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -305,3 +305,10 @@ int unlink_or_warn(const char *file)
 	return rc;
 }
 
+const char *git_custom_home(void)
+{
+	const char *val = getenv("GIT_HOME");
+	if (!val)
+		val = getenv("HOME");
+	return val;
+}
-- 
1.6.5.2

Re: [PATCH] Introduce the GIT_HOME environment variable

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> 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/

Re: [PATCH] Introduce the GIT_HOME environment variable

[Jeff King]

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

Re: [PATCH] Introduce the GIT_HOME environment variable

[Matthieu Moy]

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

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH] Introduce the GIT_HOME environment variable

[Michael J Gruber]

Matthieu Moy venit, vidit, dixit 21.12.2009 17:26:
> 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