Am Mo., 3. März 2025 um 11:33 Uhr schrieb Patrick Steinhardt [off-list ref]:

On Fri, Feb 28, 2025 at 06:15:42AM -0800, Junio C Hamano wrote:

quoted

Patrick Steinhardt [off-list ref] writes:

quoted

I suspect that most environment variables shouldn't matter (for now), so
overall the duplication may be acceptable:

  - We need to unset a couple of variables, but we can probably reuse
    logic `git rev-parse --local-env-vars`.

  - We need to ask Git to not read the configuration, which we can do by
    setting a couple of envvars. This should be manageable.

"Provide a controlled environment where Git pretends this is the
$HOME and that is the $AUTHOR_NAME and so on" is much more
preferrable than "Tell it not to read", no?

Maybe. I guess for unit tests it's a lot less clear cut as most of the
tests won't depend on such a controlled environment. So sanitizing the
environment would be a good enough first step for me, and if we see
demand for making specific information available to lots of tests we
could still start to expose those at a later point.

Since I haven't been following the list I don't know what the plan is
regarding the different test sets/framework. But, unless they are
meant to be completely separate or rewritten right away, I would say
that both shell tests and C tests (whatever framework) should run in
the same environment, and this should be a controlled environment in
terms of git and other config files (which means set up a separate
HOME) and the most relevant env vars (test-lib.sh tries to do that,
too).

Of course, if the author already wants to do both steps right now I
won't complain :)

Nah, I had a hard time just reading the failing unit-test and figuring
out how to deal with it - GIT_TEST_OPTIONS=`-i -v` does nothing for
unit-tests, and I yet have to find documentation on them. I do
understand why you want a solution in C, not a shell wrapper. (Though
you have one right now ...)

I'd rather leave this to those "in the know", or "in the want" ;-)

Michael