On 2020-05-16 at 11:02:48, Martin Ågren wrote:
> So we need to pass this capability for the SHA-256 tests to run ok. But
> if we start passing "object-format=sha1" unconditionally at this point
> in the series, the tests will fail:
>
> error: 'grep expected flush after ls-refs arguments err' didn't find
> a match in:
> fatal: unknown capability 'object-format=sha1'
>
> That is, we don't yet actually implement "object-format" handling. So
> this will still fail with SHA-256 ("unknown capability"), just that once
> the implementation is in place, the SHA-256 tests will pass (as will the
> normal SHA-1 runs). Do I understand that correctly?
Yes, that's correct.
> Or put differently, by the end of the series, we can do this:
>
> diff --git a/t/t5704-protocol-violations.sh b/t/t5704-protocol-violations.sh
> index 47e78932b9..22993812e2 100755
> --- a/t/t5704-protocol-violations.sh
> +++ b/t/t5704-protocol-violations.sh
> @@ -6,14 +6,11 @@ communications if the other side says something
> unexpected. We are mostly
> making sure that we do not segfault or otherwise behave badly.'
> . ./test-lib.sh
>
> -# If we don't print the object format, we'll fail for a spurious reason: the
> -# mismatched object format.
> +# If we don't print the object format, we might fail for a spurious reason:
> +# the mismatched object format.
> print_object_format () {
> local algo=$(test_oid algo) &&
> - if test "$algo" != "sha1"
> - then
> - packetize "object-format=$algo"
> - fi
> + packetize "object-format=$algo"
> }
>
> test_expect_success 'extra delim packet in v2 ls-refs args' '
>
> Should we? (And if we do, we might as well drop this function and inline
> the whole thing, IMHO.)
We certainly can. I'll move this later on in the series so that we
can simplify the code.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
