From: Jeff King <peff@peff.net>
To: Andrei Rybak <rybak.a.v@gmail.com>
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 16:32:53 -0400 [thread overview]
Message-ID: <20180819203253.GA5789@sigill.intra.peff.net> (raw)
In-Reply-To: <73346b91-6d19-651a-c361-1666a39681f0@gmail.com>
On Sun, Aug 19, 2018 at 07:50:42PM +0200, Andrei Rybak wrote:
> > I actually think the above gives way too confusing output, when the
> > actual output is empty and we are expecting some output.
> >
> > The tester wants to hear from test_cmp "your 'git cmd' produced some
> > output when we are expecting none" as the primary message. We are
> > trying to find bugs in "git" under development, and diagnosing iffy
> > tests is secondary. But with your change, the first thing that is
> > checked is if 'expect' is an empty file and that is what we get
> > complaints about, without even looking at what is in 'actual'.
>
> I came up with two solutions for this issue:
>
> 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.
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).
If we go that route, we should make sure that test_cmp's documentation
is updated to mention that the two sides are not symmetric (and possibly
update some callers, though I'd be OK leaving ones that aren't broken by
this, and just clean them up over time).
-Peff
next prev parent reply other threads:[~2018-08-19 20:32 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 [this message]
2018-08-19 21:37 ` Andrei Rybak
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=20180819203253.GA5789@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kirr@nexedi.com \
--cc=rybak.a.v@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).