Re: [PATCH 3/6] mktag tests: test hash-object --literally and unreachable fsck

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, Jun 15 2021, Andrei Rybak wrote:

> On 14/06/2021 19:28, Ævar Arnfjörð Bjarmason wrote:
>> Extend the mktag tests to pass the tag we've created through both
>> hash-object --literally and fsck.
>> This checks that fsck itself will not complain about certain invalid
>> content if a reachable tip isn't involved. Due to how fsck works and
>> walks the graph the failure will be different if the object is
>> reachable, so we might succeed before we've created the ref.
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>> ---
>>   t/t3800-mktag.sh | 48 +++++++++++++++++++++++++++++++++++++++---------
>>   1 file changed, 39 insertions(+), 9 deletions(-)
>> diff --git a/t/t3800-mktag.sh b/t/t3800-mktag.sh
>> index 951e6d39c2a..43b67a149f8 100755
>> --- a/t/t3800-mktag.sh
>> +++ b/t/t3800-mktag.sh
>> @@ -16,6 +16,8 @@ check_verify_failure () {
>>   	message=$2 &&
>>   	shift 2 &&
>>   +	no_strict= &&
>> +	fsck_obj_ok= &&
>>   	no_strict= &&
>>   	while test $# != 0
>>   	do
>> @@ -23,7 +25,10 @@ check_verify_failure () {
>>   		--no-strict)
>>   			no_strict=yes
>>   			;;
>> -		esac &&
>> +		--fsck-obj-ok)
>> +			fsck_obj_ok=yes
>> +			;;
>> +		esac
>
> "&&" after "esac" got removed.

Thanks, will fix.

>>   		shift
>>   	done &&
>>   @@ -37,6 +42,23 @@ check_verify_failure () {
>>   			git mktag --no-strict <tag.sig
>>   		fi
>>   	'
>> +
>> +	test_expect_success "setup: $subject" '
>> +		# Reset any leftover state from the last $subject
>> +		rm -rf bad-tag &&
>> +
>> +		git init --bare bad-tag &&
>> +		git -C bad-tag hash-object -t tag -w --stdin --literally <tag.sig
>> +	'
>> +
>> +	test_expect_success "hash-object & fsck unreachable: $subject" '
>> +		if test -n "$fsck_obj_ok"
>> +		then
>> +			git -C bad-tag fsck
>> +		else
>> +			test_must_fail git -C bad-tag fsck >out 2>err
>
> This is the very end of the check_verify_failure function. It seems
> that after "out" and "err" are created here, nothing else checks their
> contents.

Well spotted, will fix this and any other such needless rederiction in a
v2 I'll send after any other reviewing quiets down.