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

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jun 30, 2008, 01:54 UTC
Message-ID: <alpine.LNX.1.00.0806292047100.19665@iabervon.org>
In-Reply-To: <alpine.DEB.1.00.0806300134200.9925@racer>

On Mon, 30 Jun 2008, Johannes Schindelin wrote:

Show 25 quoted lines

> Hi,
> 
> On Sun, 29 Jun 2008, Daniel Barkalow wrote:
> 
> > On Sun, 29 Jun 2008, Johannes Schindelin wrote:
> > 
> > > 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.
> > 
> > Why should .git/config get written?
> 
> Because the user asked for a clone, where she reasonably expects a git 
> repository with all the [core] and the initial [remote "origin"] settings 
> to be written as it should be, _even if_ setting the config to somewhere 
> else?  Hmm?

But those should be written to the location of the config file, where subsequent commands will find them, which is $GIT_CONFIG if it's set and git commands in general use it. I mean:

$ export GIT_CONFIG=/home/barkalow/something $ git clone git://git.kernel.org/pub/scm/git/git.git $ cd git $ git fetch fatal: 'origin': unable to chdir or not a git archive fatal: The remote end hung up unexpectedly

(because "git clone" currently ignores GIT_CONFIG, but "git fetch" doesn't, so it can't find the initial [remote "origin"] settings).

Show 5 quoted lines

> IMITCNVHO it would be a serious mistake to write the config somewhere else 
> with "clone".
> 
> If that still does not convince you, "git init" also writes to 
> ".git/config" regardless of the user's (possibly bogus) GIT_CONFIG.

No, "git init" has always written to GIT_CONFIG. In fact, git-clone.sh used to depend on it writing to GIT_CONFIG, which is how it caused the config file to be written into the new clone.

> It is just such a basic thing that you must _not_ use GIT_CONFIG for 
> writing with git clone or git init.

Surely, then, you must not use GIT_CONFIG when reading the options that git clone writes? But I think this reduces to "you must not use GIT_CONFIG when using a repository", which pretty much leaves "git config". And I think it's only ever *useful* for "git config" anyway.

It doesn't make much sense to ensure that "git clone" works if you have GIT_CONFIG set when nothing else works in that situation. I still don't know what setting it is good for (and the commit that introduced it explained what it did, but not why), but I think we should be consistant about whether or not it affects where git expects configuration to be.

	-Daniel
*This .sig left intentionally blank*