Re: [PATCH v2 8/9] t: allow specifying compatibility hash
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 5 quoted lines
> Finally, in this scenario, we can no longer rely on having broken
> objects work since we lack compatibility mappings to rewrite objects in
> the repository. Add a prerequisite, BROKEN_OBJECTS, that we define in
> terms of COMPAT_HASH and checks to see if creating deliberately broken
> objects is possible, so that we can disable these tests if not.
Thanks for an attention for this kind of details.
Show 24 quoted lines
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 621cd31ae1..9eb79324ee 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -1917,6 +1917,19 @@ test_lazy_prereq DEFAULT_HASH_ALGORITHM '
> test_lazy_prereq DEFAULT_REPO_FORMAT '
> test_have_prereq SHA1,REFFILES
> '
> +# BROKEN_OBJECTS is a test whether we can write deliberately broken objects and
> +# expect them to work. When running using SHA-256 mode with SHA-1
> +# compatibility, we cannot write such objects because there's no SHA-1
> +# compatibility value for a nonexistent object.
> +test_lazy_prereq BROKEN_OBJECTS '
> + ! test_have_prereq COMPAT_HASH
> +'
> +
> +# COMPAT_HASH is a test if we're operating in a repository with SHA-256 with
> +# SHA-1 compatibility.
> +test_lazy_prereq COMPAT_HASH '
> + test -n "$test_repo_compat_hash_algo"
> +'
>
> # Ensure that no test accidentally triggers a Git command
> # that runs the actual maintenance scheduler, affecting a user's