Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig

Johannes Schindelin [off-list ref] writes:

On Sun, 29 Jun 2008, Daniel Barkalow wrote:

quoted

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".

Hi,

On Sun, 29 Jun 2008, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

On Sun, 29 Jun 2008, Daniel Barkalow wrote:

quoted

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,

No.  That would break again, since then,

- $HOME/.gitconfig would be ignored again (which was the single issue my 
  patch addressed), and
- the remote information would be written into the wrong file.

Ciao,
Dscho