Re: [PATCH v2 1/6] t1300: make tests more robust with non-default ref backends
On Wed, Jan 10, 2024 at 10:01 AM Patrick Steinhardt <ps@pks.im> 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? 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?
> 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.
Show 33 quoted lines
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> 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?
Show 20 quoted lines
> test_expect_success 'git -c "key=value" support' '
> @@ -1157,10 +1162,16 @@ test_expect_success 'git -c works with aliases of builtins' '
> '
>
> test_expect_success 'aliases can be CamelCased' '
> - test_config alias.CamelCased "rev-parse HEAD" &&
> - git CamelCased >out &&
> - git rev-parse HEAD >expect &&
> - test_cmp expect out
> + test_when_finished "rm -rf repo" &&
> + git init repo &&
> + (
> + cd repo &&
> + test_commit A &&
> + git config alias.CamelCased "rev-parse HEAD" &&
> + git CamelCased >out &&
> + git rev-parse HEAD >expect &&
> + test_cmp expect out
> + )
> '
Here single quotes are used for example.
Show 13 quoted lines
> 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.
Patrick Steinhardt
