On Thu, Feb 15, 2007 at 11:43:56AM +0100, Johannes Schindelin wrote: > This was done by setting $HOME to somewhere bogus. A better method is > to reuse $GIT_CONFIG, which was invented for ignoring the global > config file explicitely. > > Technically, setting GIT_CONFIG=.git/config could be wrong, but it > passes all the tests, and we can keep the tests that way. [Yes, this is a reply to an ancient message, but your "could be wrong" turned out to be true.] I ran across a bug in the test suite today, and it is caused by this change. The problem is that setting GIT_CONFIG=.git/config means that if we change directories, then we may silently fail to read the config file. Oops. In particular, this is covering up an incorrect test in t1500. One of the things it does is more or less this: cd .git && git rev-parse --is-bare-repository and expects it to say "true". The test passes. All fine and dandy, except that it _isn't_ a bare repository, and if you run the test by hand, it returns "false." The problem is that it's looking for .git/.git/config and doesn't find it, meaning that it never sees the "core.bare = false" setting, and makes a guess from its location inside the git dir. We could set GIT_CONFIG=$(pwd)/.git/config, but then that fails if the test creates other repos. We could go back to setting HOME to something bogus, but then we have no way to suppress the reading of /etc/gitconfig (the only way to do so, I think, is to set GIT_CONFIG). So I think we are stuck adding in some environment magic to suppress the reading of ETC_GITCONFIG, and doing something like: unset GIT_CONFIG GIT_ETC_CONFIG=$(pwd)/.git/nonexistant GIT_LOCAL_CONFIG=$(pwd)/.git/nonexistant Thoughts? -Peff - 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
