On Mon, 30 Jun 2008, Johannes Schindelin wrote:

quoted text
> 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).

quoted text
> 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.

quoted text
> 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*
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html