On Mon, Sep 20 2021, Taylor Blau wrote:
> On Sun, Sep 19, 2021 at 10:47:16AM +0200, Ævar Arnfjörð Bjarmason wrote:
>> 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
