Re: [PATCH v4 1/6] t1300: make tests more robust with non-default ref backends
- From
Christian Couder <christian.couder@gmail.com>
- Date
- Jan 29, 2024, 12:00 UTC
- Message-ID
- <CAP8UFD1=yAhv5QKDCYPfTu0=qLCyRUGt3W9y1D9XGjvJbv8wLQ@mail.gmail.com>
- In-Reply-To
- <80a74bbb567de165a8dadf0664167140e4bf0504.1706525813.git.ps@pks.im>
On Mon, Jan 29, 2024 at 12:07 PM Patrick Steinhardt <ps@pks.im> wrote:
Show 10 quoted lines
> > 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.
Show 11 quoted lines
> 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.
Show 10 quoted lines
> 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.