From: Junio C Hamano Date: Mon, 30 Jun 2008 06:20:01 GMT Subject: Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig Message-ID: <7vwsk730mm.fsf@gitster.siamese.dyndns.org> In-Reply-To: Johannes Schindelin writes: > On Sun, 29 Jun 2008, Daniel Barkalow wrote: > >> Did we even make a commitment on whether: >> >> GIT_CONFIG=foo git clone bar >> >> must ignore the environment variable, or simply doesn't necessarily obey >> it? > > I'd rather strongly argue that no matter what is the answer to this > question, we _HAVE TO_ unsetenv() GIT_CONFIG at some stage, otherwise no > .git/config will be written. > > So, this is a NACK on your patch. True. We are creating the config file for the new repository, so the initial setenv() would make sense. We _could_ save away end user's GIT_CONFIG and restore it where you unsetenv() in your patch, but I do not think it would buy us anything other than "be consistent with other programs that misbehave when end user has GIT_CONFIG". Honestly, GIT_CONFIG is purely for scripts like git-svn that muck with files that are in the config format to have a way to make sure that they access the file they intend to, and being able to use GIT_CONFIG to keep git programs from reading from $HOME/.gitconfig is primarily for giving our test scripts repeatable environment, nothing more. I think ignoring end-user GIT_CONFIG like this patch does, instead of doing random nonsense, would be a good bugfix for "git clone".