Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes:
> Since it sets GIT_DIR, it also could simply unset GIT_CONFIG, and then
> everything would just write to the config file for the new GIT_DIR. On the
> other hand, if you have GIT_CONFIG exported in your environment, and you
> set up a repository with "git clone", and clone unsets or overrides
> GIT_CONFIG, then your new repository will immediately be unusable, because
> clone will set up the config file inside the new repository, but nothing
> you run after that will look in the new repository, since everything else
> obeys the GIT_CONFIG you still have set.
Yes, I think an interactive environment that has GIT_CONFIG is
simply misconfigured.
But on the other hand, I could well imagine a script that does
this:
#!/bin/sh
GIT_CONFIG=$elsewhere; export GIT_CONFIG
do things to the $elsewhere file via git-config
git clone $something $new
talk about the $new in the $elsewhere file via git-config
(
unset GIT_CONFIG ;# I am writing the script carefully!
cd $new
do something inside the clone
)
talk more about the $new in the $elsewhere file via git-config
exit
> On the other hand, I don't see why any git command other than "git config"
> (run my the user directly) has any business looking at GIT_CONFIG, since
> it's only mentioned in the man page for git-config, and not in general for
> configuration, the wrapper, or other programs.
I think reading from the configuration file is done by
everybody, and GIT_CONFIG affects where the information is read
from. Maybe it was a misfeature. I dunno.
-
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
