On Tue, 26 Feb 2008, Junio C Hamano wrote: > 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. There's nothing in the documentation to suggest that you can use GIT_CONFIG to affect how the old repository is read, or that GIT_CONFIG doesn't affect the new repository. Actually, as far as I can tell, the configuration of a repository you're cloning (local or remote) doesn't matter at all. Note that GIT_DIR and GIT_WORK_TREE refer to the new repo, so it would be surprising for GIT_CONFIG to refer to the old one. > Without setting GIT_CONFIG explicitly how would you set the > configuration that is about the new repository clone creates? By setting GIT_DIR, which also makes everything else work right. (We may want to probe the old repository some by setting GIT_DIR to it temporarily, but we can just collect information that way, and then set it to the new one to configure it and set it up.) My current design is to collect some initial information, create directories, and then set the work tree and git dir. Then we run fetch, configure things, etc., in the new context. I'm not sure why git-clone.sh doesn't just set GIT_DIR to whatever it decides the git dir with be, and leave GIT_CONFIG alone (or unset it, if it's expected to mean something different). -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
