Jeff King [off-list ref] writes:
I think anytime you would use GIT_CONFIG_NOSYSTEM over --local, it is an
indication that the test is trying to check how multiple sources
interact. And the right thing to do for them is to set GIT_ETC_GITCONFIG
to some known quantity. We just couldn't do that before, so we skipped
it. IOW, something like the patch below (on top of yours).
OK, that way we can make sure that "multiple sources" operations do
look at the system-wide stuff.
Note that the
commands that are doing a "--get" and not a "--list" don't actually seem
to need either (because they are getting the values out of the local
file anyway), so we could drop the setting of GIT_ETC_GITCONFIG from
them entirely.
"either" meaning "we do not need to add --local and we do not need
GIT_CONFIG_NOSYSTEM"?
On Thu, Sep 29, 2016 at 11:13:45AM -0700, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
I think anytime you would use GIT_CONFIG_NOSYSTEM over --local, it is an
indication that the test is trying to check how multiple sources
interact. And the right thing to do for them is to set GIT_ETC_GITCONFIG
to some known quantity. We just couldn't do that before, so we skipped
it. IOW, something like the patch below (on top of yours).
OK, that way we can make sure that "multiple sources" operations do
look at the system-wide stuff.
Exactly.
quoted
Note that the
commands that are doing a "--get" and not a "--list" don't actually seem
to need either (because they are getting the values out of the local
file anyway), so we could drop the setting of GIT_ETC_GITCONFIG from
them entirely.
"either" meaning "we do not need to add --local and we do not need
GIT_CONFIG_NOSYSTEM"?
Yes. I didn't test it with your core.abbrev patch 4/4, but I _didn't_
have to touch their expected output after pointing them at a non-empty
etc-gitconfig file in the trash directory. Which implies to me they
don't care either way (which makes sense; they are asking for a specific
key which is supposed to be found in one of the other files).
-Peff