All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrei Rybak <rybak.a.v@gmail.com>
To: Jeff King <peff@peff.net>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"SZEDER Gábor" <szeder.dev@gmail.com>,
	"Git mailing list" <git@vger.kernel.org>,
	"Kirill Smelkov" <kirr@nexedi.com>
Subject: Re: [PATCH] t5310-pack-bitmaps: fix bogus 'pack-objects to file can use bitmap' test
Date: Sun, 19 Aug 2018 23:37:59 +0200	[thread overview]
Message-ID: <aedb7f33-65cc-5d63-4e7e-dd5f37831e19@gmail.com> (raw)
In-Reply-To: <20180819203253.GA5789@sigill.intra.peff.net>

On 19/08/18 22:32, Jeff King wrote:
> On Sun, Aug 19, 2018 at 07:50:42PM +0200, Andrei Rybak wrote:
> 
>>   1. Check both files at the same time (combination with Gábor's
>>      function):
>>
>> 	test_cmp () {
>> 		if test "$1" != - &&
>> 		   test "$2" != - &&
>> 		   ! test -s "$1" && 
>> 		   ! test -s "$2"
>> 		then
>> 			error "bug in test script: using test_cmp to check empty file; use test_must_be_empty instead"
>> 		fi
>> 		test_cmp_allow_empty "$@"
>> 	}
>>
>>      This will still be reporting to the developer clearly, but
>>      will only catch cases exactly like the bogus test in t5310.
> 
> Doesn't that have the opposite issue? If we expect non-empty output but
> the command produces empty output, we'd say "bug in the test script".
> But that is not true at all; it's a failed test.

No. Only when both "$1" and "$2" are empty files will the function above
report "bug in test script". From patch's commit message:

  ... both invocations produce empty 'pack{a,b}.objects' files, and the
  subsequent 'test_cmp' happily finds those two empty files identical.

That's what I meant by "will only catch cases exactly like the bogus
test in t5310".

However ...

> If we assume that "expect" is first (which is our convention but not
> necessarily guaranteed), then I think the best logic is something like:
> 
>   if $1 is empty; then
>     bug in the test script
>   elif test_cmp_allow_empty "$@"
>     test failure
> 
> We do not need to check $2 at all. An empty one is either irrelevant (if
> the expectation is empty), or a test failure (because it would not match
> the non-empty $1).

... this is indeed a better solution. I written out the cases for
updated test_cmp to straighten out my thinking:

 * both $1 and $2 are empty:
     bogus test:
       needs either fixing generation of both expect and actual
       or switching to test_must_be_empty
   OR
     bogus helper function, as Gábor described above:
       needs to switch to test_cmp_allow_empty
 
 * $1 is non-empty && $2 is empty
   proceeding with test
   test failure from GIT_TEST_CMP
 
 * $1 is empty && $2 is non-empty
   bogus test - needs either switching to test_must_be_empty
   (and after that test_must_be_empty will report failure)
   or fixing generation of expect (and after that test result
   depends on contents).
 
 * both $1 and $2 are non-empty
   proceeding with test
   result depends on contents

  reply	other threads:[~2018-08-19 21:38 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-14 11:47 [PATCH] t5310-pack-bitmaps: fix bogus 'pack-objects to file can use bitmap' test SZEDER Gábor
2018-08-14 21:49 ` Jeff King
2018-08-16 20:51 ` Andrei Rybak
2018-08-16 22:36   ` Junio C Hamano
2018-08-17 17:39     ` SZEDER Gábor
2018-08-17 19:27       ` Andrei Rybak
2018-08-17 20:09         ` Junio C Hamano
2018-08-19 17:50           ` Andrei Rybak
2018-08-19 20:32             ` Jeff King
2018-08-19 21:37               ` Andrei Rybak [this message]
2018-08-19 21:43                 ` Jeff King
2018-08-21 21:52                   ` Junio C Hamano
2018-08-17 20:15         ` SZEDER Gábor
2018-08-22 18:14   ` Matthew DeVore
2018-08-27 10:22 ` Kirill Smelkov
2018-08-27 23:04   ` Jeff King
2018-08-28  6:37     ` Kirill Smelkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aedb7f33-65cc-5d63-4e7e-dd5f37831e19@gmail.com \
    --to=rybak.a.v@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kirr@nexedi.com \
    --cc=peff@peff.net \
    --cc=szeder.dev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.