Subject: Re: [PATCH v2 1/6] t1300: make tests more robust with non-default ref backends

From: Patrick Steinhardt <[email-masked]>
Date: Wed, 24 Jan 2024 09:52:50 +0100

On Tue, Jan 23, 2024 at 05:15:48PM +0100, Christian Couder wrote:
> On Wed, Jan 10, 2024 at 10:01 AM Patrick Steinhardt <[email-masked]> wrote:
> >
> > The t1300 test suite exercises the git-config(1) tool. To do so we
> > overwrite ".git/config" to contain custom contents.
> 
> Here "we" means "tests in t1300" I guess.
> 
> > While this is easy
> > enough to do, it may create problems when using a non-default repository
> > format because we also overwrite the repository format version as well
> > as any potential extensions.
> 
> But I am not sure that "we" in the above sentence is also "tests in
> t1300". I think overwriting the repo format version and potential
> extensions is done by other tests, right? Anyway it would be nice to
> clarify this.
> 
> > With the upcoming "reftable" ref backend
> > the result is that we may try to access refs via the "files" backend
> > even though the repository has been initialized with the "reftable"
> > backend.
> 
> Not sure here also what "we" is. When could refs be accessed via the
> "files" backend even though the repo was initialized with the
> "reftable" backend?

Yeah, I've rephrased all of these to sey "the tests" or something
similar.

> Does this mean that some of the tests in t1300 try to access refs via
> the "files" backend while we may want to run all the tests using the
> reftable backend?

Exactly. We overwrite the ".git/config", which contains the "refStorage"
extension that tells us to use the "reftable" backend. So the extension
is gone, and thus Git would fall back to use the "files" backend
instead, which will fail.

> > 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.
> 
> Not sure what exactly is discarding extensions. Also robust is not
> very clear. It would be better to give at least an example of how
> things could fail.

Hm. I don't really know how to phrase this better. The preceding
paragraph already explains why we're discarding the extension and what
the consequence is. I added a sentence saying ", which will cause
failures when trying to access any refs."

> > Signed-off-by: Patrick Steinhardt <[email-masked]>
> > ---
> >  t/t1300-config.sh | 74 ++++++++++++++++++++++++++++++-----------------
> >  1 file changed, 48 insertions(+), 26 deletions(-)
> >
> > diff --git a/t/t1300-config.sh b/t/t1300-config.sh
> > index f4e2752134..53c3d65823 100755
> > --- a/t/t1300-config.sh
> > +++ b/t/t1300-config.sh
> > @@ -1099,13 +1099,18 @@ test_expect_success SYMLINKS 'symlink to nonexistent configuration' '
> >  '
> >
> >  test_expect_success 'check split_cmdline return' "
> > -       git config alias.split-cmdline-fix 'echo \"' &&
> > -       test_must_fail git split-cmdline-fix &&
> > -       echo foo > foo &&
> > -       git add foo &&
> > -       git commit -m 'initial commit' &&
> > -       git config branch.main.mergeoptions 'echo \"' &&
> > -       test_must_fail git merge main
> > +       test_when_finished 'rm -rf repo' &&
> > +       git init repo &&
> > +       (
> > +               cd repo &&
> > +               git config alias.split-cmdline-fix 'echo \"' &&
> > +               test_must_fail git split-cmdline-fix &&
> > +               echo foo >foo &&
> > +               git add foo &&
> > +               git commit -m 'initial commit' &&
> > +               git config branch.main.mergeoptions 'echo \"' &&
> > +               test_must_fail git merge main
> > +       )
> >  "
> 
> Maybe, while at it, this test could be modernized to use single quotes
> around the test code like:
> 
> test_expect_success 'check split_cmdline return' '
> ...
> '
> 
> or is using double quotes still Ok?

In general single quotes are preferable. This test is using quotes
internally, which I guess is the reason why we didn't. Happy to change
while at it.

[snip]
> >  test_expect_success 'git -c does not split values on equals' '
> > @@ -2009,11 +2020,11 @@ test_expect_success '--show-origin getting a single key' '
> >  '
> >
> >  test_expect_success 'set up custom config file' '
> > -       CUSTOM_CONFIG_FILE="custom.conf" &&
> > -       cat >"$CUSTOM_CONFIG_FILE" <<-\EOF
> > +       cat >"custom.conf" <<-\EOF &&
> >         [user]
> >                 custom = true
> >         EOF
> > +       CUSTOM_CONFIG_FILE="$(test-tool path-utils real_path custom.conf)"
> >  '
> 
> This looks like a test modernization, but maybe it's part of making
> the tests more robust. Anyway it might be a good idea to either talk a
> bit about that in the commit message or to move it to a preparatory
> commit if it's a modernization and other modernizations could be made
> in that preparatory commit.
> 
> Otherwise this patch looks good to me.

Yup, this has also been pointed out by others. Will mention in the
commit message.

Patrick