Re: [PATCH] Fix premature call to git_config() causing t1020-subdirectory to fail

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 27, 2008, 20:09 UTC
Message-ID: <7vy796rwkb.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LNX.1.00.0802271430130.19665@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

Show 8 quoted lines

> Since it sets GIT_DIR, it also could simply unset GIT_CONFIG, and then 
> everything would just write to the config file for the new GIT_DIR. On the 
> other hand, if you have GIT_CONFIG exported in your environment, and you 
> set up a repository with "git clone", and clone unsets or overrides 
> GIT_CONFIG, then your new repository will immediately be unusable, because 
> clone will set up the config file inside the new repository, but nothing 
> you run after that will look in the new repository, since everything else 
> obeys the GIT_CONFIG you still have set.

Yes, I think an interactive environment that has GIT_CONFIG is simply misconfigured.

But on the other hand, I could well imagine a script that does this:

	#!/bin/sh
	GIT_CONFIG=$elsewhere; export GIT_CONFIG
        do things to the $elsewhere file via git-config
        git clone $something $new
        talk about the $new in the $elsewhere file via git-config
	(
        	unset GIT_CONFIG ;# I am writing the script carefully!
		cd $new
                do something inside the clone
	)
        talk more about the $new in the $elsewhere file via git-config
	exit

> On the other hand, I don't see why any git command other than "git config" 
> (run my the user directly) has any business looking at GIT_CONFIG, since 
> it's only mentioned in the man page for git-config, and not in general for 
> configuration, the wrapper, or other programs.

I think reading from the configuration file is done by everybody, and GIT_CONFIG affects where the information is read from. Maybe it was a misfeature. I dunno.