Re: [PATCH] config: use GIT_CONFIG in git config sequence

[Mateusz Nowotynski <maxmati4@gmail.com>]

On Sun, Apr 26, 2020 at 03:32:51PM -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Philip Oakley <philipoakley@iee.email> writes:
> >
> >> Mateusz's original problem was with discovery of these env variables,...
> >
> > I somehow doubt it.  
> >
> > Certainly, defeating /etc/gitconfig should be a part of the solution
> > to the "I want a stable environment to run tests reproducibly,
> > without getting affected by random settings the testing user may get
> > affected" problem.  It is not enough to defeat $HOME/.gitconfig (and
> > its xdg variant).
> >
> > But I didn't get the feeling that Mateusz was even aware of the need
> > ...
> 
> After re-reading the patch that started this thread, I suspect the
> reason Mateusz did not mention GIT_CONFIG_NOSYSTEM could be because
> he was aware of the need to defeat /etc/gitconfig, and was already
> using it.  There was no discovery issue---to somebody who would
> propose the patch under discussion to solve "I want a stable
> environment for testing", /etc/gitconfig was a solved problem.
Yes, this is exactly the case, I'm fully aware of GIT_CONFIG_NOSYSTEM so
there is no problem with system wide config file. Anyway if you want to
improve its discoverability I can suggest moving description from
git-config to git since it's influences all git commands not only git
config.
> And unfortunately we do not have GIT_CONFIG_NO_GLOBAL; so there is
> nothing to discover there, either X-<.  If we were to add such an
> environment, we need to make sure that it is discoverable ;-)
I think it will fully solve my problem so if you are willing to accept
it I can do the implementation, it shouldn't be complex anyway.
Regarding the discoverability I think the documentation should be put
together with GIT_CONFIG_NOSYSTEM since they are very close to each
other.
> I still think setting up a directory that can be used as a stable
> $HOME replacement and pointing at it during the test, while
> declining the system-wide one with GIT_CONFIG_NOSYSTEM, is the right
> approach for "stable test environment" problem.
We have pretty "stable test environment" that is running in CI and it's
working really well and stable. Problem starts with developers machines.
We would like pose as low requirements on them as possible, ideally it
would be just given range of go, ruby and git version that we use. I
know that it will be ideal to just overwrite $HOME with some temp
directory but reality is even if it's not fully UNIX compliant there are
tools that will rely on user $HOME to provide those requirements (go,
ruby and git). I think that in such case it's better to add this small
feature to git then go and fix every tool in the world. Currently we
found issues only with go cache and mentioned earlier asdf version, but
I expect more of them as people come and go.