On Mon, 30 Jun 2008, Johannes Schindelin wrote: > 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). > 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* -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
