On Mon, Jan 29, 2024 at 12:07 PM Patrick Steinhardt <ps@xxxxxx> wrote: > > The t1300 test suite exercises the git-config(1) tool. To do so, the > test overwrites ".git/config" to contain custom contents in several > places with code like the following: > > ``` > cat > .git/config <<\EOF > ... > EOF > ``` I thought about using a function that would overwrite a config file safely as it would still copy the repository format version and other extension information to the new config file, but a number of tests even do `rm .git/config`, so it wouldn't be enough. > While this is easy enough to do, it may create problems when using a > non-default repository format because this causes us to overwrite the > repository format version as well as any potential extensions. With the > upcoming "reftable" ref backend the result is that Git would try to > access refs via the "files" backend even though the repository has been > initialized with the "reftable" backend, which will cause failures when > trying to access any refs. > > Ideally, we would rewrite the whole test suite to not depend on state > written by previous tests, but that would result in a lot of changes in > this test suite. I agree that the whole test script would need significant work. > Instead, we only refactor tests which access the refdb > to be more robust by using their own separate repositories, which allows > us to be more careful and not discard required extensions. > > Note that we also have to touch up how the CUSTOM_CONFIG_FILE gets > accessed. This environment variable contains the relative path to a > custom config file which we're setting up. But because we are now using > subrepositories, this relative path will not be found anymore because > our working directory changes. This issue is addressed by storing the > absolute path to the file in CUSTOM_CONFIG_FILE instead.
