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
next prev parent 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.