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