Am Mo., 3. März 2025 um 11:33 Uhr schrieb Patrick Steinhardt <ps@xxxxxx>: > > On Fri, Feb 28, 2025 at 06:15:42AM -0800, Junio C Hamano wrote: > > Patrick Steinhardt <ps@xxxxxx> writes: > > > 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
