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

[Junio C Hamano <gitster@pobox.com>]

Daniel Barkalow <barkalow@iabervon.org> writes:

> On Tue, 26 Feb 2008, Johannes Schindelin wrote:
>
>> Hi,
>> 
>> On Tue, 26 Feb 2008, Daniel Barkalow wrote:
>> 
>> > Actually, I think I'll be leaving CONFIG_ENVIRONMENT alone entirely; I 
>> > was only using it to override the setting that t5505 uses, but t5505 is 
>> > just wrong to set it. So this is the right placement of git_config(), 
>> > and the setenv and unsetenv aren't needed.
>> 
>> Well, existing git-clone.sh sets GIT_CONFIG.  So we have to unset any 
>> existing GIT_CONFIG at least.
>
> As far as I can tell, that's a flaw in git-clone.sh; if the user has set 
> GIT_CONFIG, it shouldn't be the case that every program other than 
> git-clone obeys it while git-clone ignores it. (On the other hand, 
> possibly every program other than git-config should ignore it, since it's 
> only documented as affecting git-config.) git-clone.sh only sets it, I 
> think, because it runs programs from the wrong context for them to do the 
> right thing by default, not because it's specifically trying to override a 
> user-provided setting.

When cloning locally, there are two repositories involved, and
GIT_CONFIG if exists in the environment talks about the original
one that gets cloned.  Without setting GIT_CONFIG explicitly how
would you set the configuration that is about the new repository
clone creates?

And to be consistent, if cloning remotely, we should do the
same, which means GIT_CONFIG should be reset to point at the
configuration file inside the new repository, be it .git/config
or $repo/config (if bare).

I think that is the reason behind it.