Eric Wong <normalperson@xxxxxxxx> writes:
> Junio C Hamano <junkio@xxxxxxx> wrote:
> ...
>> I am still not sure what good GIT_CONFIG would be to completely
>> override everything else, though.
>
> I just started using GIT_CONFIG in the experimental version of
> git-svn[1] which allows me to use .git/svn/config for tracking some
> metadata bits.
>
> I didn't want to pollute the users' .git/config with automatically read
> and state data in .git/config; so I started using .git/svn/config to
> avoid littering .git/svn/ with any tiny pieces of data I might need.
Ah, so the intended usage is to use git-config to store in and
retrieve from a file that does not have anything to do with the
core git data, and the using script would say:
value=$(GIT_CONFIG=$that_extra_file git-config --get some.variable)
... do whatever with $value which does not have
... anything to do with git core itself
gitvalue=$(git-config --get some.git.variable)
... use gitvalue which has some relevance to git core
GIT_CONFIG=$that_extra_file git-config some.variable $newvalue
I was more worried about the fact that the current GIT_CONFIG
totally *ignores* the variables in .git/config. With a
narrower-than-usual umask, not reading core.sharedrepository
would result in quite an undesired result. But as long as the
intended usage follows the patter like above, in other words,
the user (a script) will never export GIT_CONFIG when using core
git plumbing or porcelain, I think it is Ok.
-
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