Re: [PATCH v3 2/5] environment.c: remove test-specific "ignore_untracked..." variable

On Mon, Sep 20 2021, Taylor Blau wrote:

On Sun, Sep 19, 2021 at 10:47:16AM +0200, Ævar Arnfjörð Bjarmason wrote:

quoted

Instead of the global ignore_untracked_cache_config variable added in
dae6c322fa1 (test-dump-untracked-cache: don't modify the untracked
cache, 2016-01-27) we can make use of the new facility to set config
via environment variables added in d8d77153eaf (config: allow
specifying config entries via envvar pairs, 2021-01-12).

It's arguably a bit hacky to use setenv() and getenv() to pass
messages between the same program, but since the test helpers are not
the main intended audience of repo-settings.c I think it's better than
hardcoding the test-only special-case in prepare_repo_settings().

Hmm. I tend to agree that using (a wrapper over) setenv() to pass
messages between the test helper and the rest of Git is a little bit of
a hack.

Everything you wrote should work based on my understanding of the
config-over-environment-variable stuff added recently. But I wish that
it didn't involve losing some grep-ability between the test-helper and
library code.

Does that grep-ability between the two have any reason to exist? The
only reason we need this special-case in the test helper is because it's
not setting up "normal" config.

It could also be made to do so, that's a bigger behavior change than
this narrow change, but likewise we'd just end up with a "git config
core.untrackedCache keep" in some test *.sh somewhere, and no
grep-ability between the test helper and library code.

But now that we have GIT_CONFIG_COUNT etc. using the environment has
become a perfectly fine way to pass this data along, we could also do
that in the *.sh setup, but this was easier, and also easier to
guarantee correctness with the new x*() wrapper.

IOW just because it's called t/helper/test-dump-untracked-cache.c it
really doesn't have any business reaching into the guts of
repo-settings.c to tweak how we set up core.untrackedCache. The only
reason it did was because the code pre-dated the
GIT_CONFIG_{COUNT,KEY,VALUE} implementation.

So I wouldn't be sad to see this patch get dropped, and I also wouldn't
be overly sad to see it get picked up, either. But I don't think it's a
necessary step, and we may be slightly better without it.

Thanks,
Taylor