Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > On Tue, 26 Feb 2008, Johannes Schindelin wrote: > >> Hi, >> >> On Tue, 26 Feb 2008, Daniel Barkalow wrote: >> >> > Actually, I think I'll be leaving CONFIG_ENVIRONMENT alone entirely; I >> > was only using it to override the setting that t5505 uses, but t5505 is >> > just wrong to set it. So this is the right placement of git_config(), >> > and the setenv and unsetenv aren't needed. >> >> Well, existing git-clone.sh sets GIT_CONFIG. So we have to unset any >> existing GIT_CONFIG at least. > > As far as I can tell, that's a flaw in git-clone.sh; if the user has set > GIT_CONFIG, it shouldn't be the case that every program other than > git-clone obeys it while git-clone ignores it. (On the other hand, > possibly every program other than git-config should ignore it, since it's > only documented as affecting git-config.) git-clone.sh only sets it, I > think, because it runs programs from the wrong context for them to do the > right thing by default, not because it's specifically trying to override a > user-provided setting. When cloning locally, there are two repositories involved, and GIT_CONFIG if exists in the environment talks about the original one that gets cloned. Without setting GIT_CONFIG explicitly how would you set the configuration that is about the new repository clone creates? And to be consistent, if cloning remotely, we should do the same, which means GIT_CONFIG should be reset to point at the configuration file inside the new repository, be it .git/config or $repo/config (if bare). I think that is the reason behind it. - 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
