From: Junio C Hamano <junkio@cox.net>
Date: Thu, 15 Feb 2007 08:46:23 GMT
Subject: Re: [PATCH] config: read system-wide defaults from /etc/gitconfig
Message-ID: <7v4ppnhkps.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7v1wkshtxg.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

> I am not quite sure how $GIT_CONFIG and $GIT_CONFIG_LOCAL were
> meant to be used.  Are there any *real* users?  With lack of
> information on the intended uses of these two environment
> variables, I hacked up the following tweaks on top of the above
> defined semantics, to imitate what I _think_ was the original
> intention.  The hacked one goes like this:
>
>  - $GIT_CONFIG environment, if set, names a file to be read
>    first.  We read it first.
>
>  - If $GIT_CONFIG is unset, then $GIT_CONFIG_SYSTEM (or
>    /etc/gitconfig) and $HOME/.gitconfig are read, as above.
>
>  - Next file to be read is $GIT_CONFIG_LOCAL (if set) or
>    $GIT_DIR/config.  When reading this file, if we read from
>    $GIT_CONFIG earlier, we read only "core.*" section from it.
> ...

Addendum.

Judging from the way builtin-config.c::get_value() uses it, I
think whoever invented $GIT_CONFIG_LOCAL as a parallel to
$GIT_INDEX_FILE and $GIT_OBJECT_DIRECTORY, in other words, what
usually appear under $GIT_DIR can be placed somewhere completely
different.  So I think the above "hack" I described still honors
its intended use.

I am still not sure what good GIT_CONFIG would be to completely
override everything else, though.