Hi,

On Wed, 14 Feb 2007, Junio C Hamano wrote:

quoted text
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> I think we need to have a way to disable this setting, perhaps
> >> via an environment variable.
> >
> > Yes. Just set GIT_CONFIG=/what/ever, and it no longer reads from 
> > ~/.gitconfig or $prefix/etc/gitconfig.
> 
> I think GIT_CONFIG and GIT_LOCAL_CONFIG environment variables are 
> seriously misdesigned.

Okay for GIT_LOCAL_CONFIG. I do not remember off-hand who wanted it 
(Jakub? Pasky?), but it was in the context of gitweb.

However, GIT_CONFIG is meant to parse arbitrary config files. You can 
literally say

	GIT_CONFIG=/windows/C/WINNT/system.ini git config drivers.wave

and get the value for "wave" in system.ini, section [drivers].

BTW I find the HOME mangling in test-lib.sh insane. Here's a replacement:

-- snip --
[PATCH] Make tests independent of global config files

This was done by setting $HOME to somewhere bogus. A better method is
to reuse $GIT_CONFIG, which was invented for ignoring the global
config file explicitely.

Technically, setting GIT_CONFIG=.git/config could be wrong, but it
passes all the tests, and we can keep the tests that way.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
 t/test-lib.sh |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index 37822fc..a403fe0 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -255,8 +255,8 @@ test_done () {
 PATH=$(pwd)/..:$PATH
 GIT_EXEC_PATH=$(pwd)/..
 GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
-HOME=$(pwd)/trash
-export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR HOME
+GIT_CONFIG=.git/config
+export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG
 
 GITPERLLIB=$(pwd)/../perl/blib/lib:$(pwd)/../perl/blib/arch/auto/Git
 export GITPERLLIB
-- snap --

quoted text
>  - $GIT_CONFIG_SYSTEM environment, if set, names a file to be
>    read first.  It defaults to /etc/gitconfig.  You can set it
>    to /dev/null to avoid using /etc/gitconfig if you have
>    specific need.
> 
>  - Then $HOME/.gitconfig is read.
> 
>  - Then $GIT_DIR/config is read.

Yes, you can. But I'd rather not. The contents of /etc/gitconfig should be 
changed with care, and _if_ they are changed, you should be forced to 
override the settings explicitely in $HOME/.gitconfig.

Of course, this assumes a sensible administrator.

quoted text
> I am not quite sure how $GIT_CONFIG and $GIT_CONFIG_LOCAL were meant to 
> be used.

As I said, I _think_ it was the gitweb people, who wanted to have this to 
point at some gitweb specific, global (i.e. repo-independent) config.

quoted text
>  - $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.

I am all for removing support for $GIT_CONFIG_LOCAL. IMHO it really does 
not make sense, for the reasons you told in your email: important per-repo 
information would be ignored, but not global or system-wide settings.

GIT_CONFIG should be used when reading a config which is totally unrelated 
to a repository. (Or for testing.)

But this "core.*" stuff is insane. Please no.

BTW just to clarify a subtlety in the code (which looks ugly at first, but 
nothing else makes sense):

When using --get-all, (with the patch I sent out earlier) git-config reads 
/etc/gitconfig first, then ~/.gitconfig, and then .git/config.

When not using --get-all, it reads .git/config first, and if nothing was 
found yet, reads ~/.gitconfig, and if still nothing was found, 
/etc/gitconfig.

It seems convoluted at first, but is the only way we can check for unique 
settings. For example, if the system-wide default for "color.diff" is 
"false", but in your repo it is "auto", it should _not_ warn of ambiguous 
settings, while it should warn if you have both settings in .git/config.

Outside of git-config, such unique variables are always handled in a 
last-wins manner, so we are safe.

I would feel much better, though, if supporters of /etc/gitconfig spoke a 
little bit louder, before actually doing something about it.

Ciao,
Dscho

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html