Re: [PATCH] config: read system-wide defaults from /etc/gitconfig

From: Junio C Hamano <junkio@cox.net>
Date: Feb 15, 2007, 11:25 UTC
Message-ID: <7vvei3d5n5.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0702151126300.448@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 6 quoted lines

> 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.
> ...
> But this "core.*" stuff is insane. Please no.

Ok, Eric's example and yours made it clear that GIT_CONFIG is an interface meant to reuse (or abuse) git-config to read some file that is not at all related to git, and should never be used by other plumbing. As long as that is clear (could we have that in the documentation, by the way, please?), I have no problem with that.

In fact, I am very happy that we do not have to do that insane "core.*" stuff, which I thought was needed purely because somebody was trying to use GIT_CONFIG to prevent plumbing and porcelain from reading core configuration variables that are per repository in nature.

As I said in my other message, GIT_LOCAL_CONFIG is parallel to GIT_OBJECT_DIRECTORY and GIT_INDEX_FILE, and I am Ok with the way it is handled by the current code.

I mildly disagree with you on having an ability to disable /etc/gitconfig. This is necessary in the real world (in the same sense as "adduser" can be told not to copy skeltons by creating an empty home directory beforehand), even if we do not consider the fact that it would help gaining repeatable results from our test scripts (remember, using GIT_CONFIG to make plumbing and porcelain read from there would set a bad example, even when it is pointing at .git/config).

I've queued that insane "core.*" stuff in 'pu' and pushed out, but I'll drop that topic altogether. But before doing that, it's past my bedtime ;-).