From: Junio C Hamano <gitster@pobox.com>
To: Andrei Rybak <rybak.a.v@gmail.com>
Cc: git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Michael J Gruber" <git@grubix.eu>, "Jeff King" <peff@peff.net>,
"Patrick Steinhardt" <ps@pks.im>,
"Michael Haggerty" <mhagger@alum.mit.edu>
Subject: Re: [PATCH v1 3/7] t1010: assert empty output of mktree
Date: Mon, 13 Mar 2023 14:38:06 -0700 [thread overview]
Message-ID: <xmqqsfe8s56p.fsf@gitster.g> (raw)
In-Reply-To: <20230312201520.370234-5-rybak.a.v@gmail.com> (Andrei Rybak's message of "Sun, 12 Mar 2023 21:15:16 +0100")
Andrei Rybak <rybak.a.v@gmail.com> writes:
> test_expect_success 'mktree refuses to read ls-tree -r output (1)' '
> - test_must_fail git mktree <all >actual
> + test_must_fail git mktree <all >actual &&
> + test_must_be_empty actual
> '
>
> test_expect_success 'mktree refuses to read ls-tree -r output (2)' '
> - test_must_fail git mktree <all.withsub >actual
> + test_must_fail git mktree <all.withsub >actual &&
> + test_must_be_empty actual
> '
I am ambivalent. As long as a failing command signals its failure
with its non-zero exit status value, the consumer of the output
should not blindly use the output from such a failing command. Is
there a strong reason why we want users rely on the command to be
silent when it fails?
An obvious alternative is to stop producing "actual" file, and it
might be a better idea; unless there is a good reason why we should
expect the command to be silent, that is.
Thanks.
next prev parent reply other threads:[~2023-03-13 21:38 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-12 20:15 [PATCH v1 0/7] t: fix unused files, part 1 Andrei Rybak
2023-03-12 20:15 ` [PATCH v1 1/7] t1005: assert output of ls-files Andrei Rybak
2023-03-14 8:51 ` Michael J Gruber
2023-03-18 15:17 ` Andrei Rybak
2023-03-12 20:15 ` [PATCH v1 1/1] t1507: assert output of rev-parse Andrei Rybak
2023-03-12 20:24 ` Andrei Rybak
2023-03-12 20:15 ` [PATCH v1 2/7] t1006: assert error output of cat-file Andrei Rybak
2023-03-12 20:15 ` [PATCH v1 3/7] t1010: assert empty output of mktree Andrei Rybak
2023-03-13 21:38 ` Junio C Hamano [this message]
2023-03-12 20:15 ` [PATCH v1 4/7] t1302: don't create unused file Andrei Rybak
2023-03-12 20:15 ` [PATCH v1 5/7] t1400: assert output of update-ref Andrei Rybak
2023-03-12 20:15 ` [PATCH v1 6/7] t1404: don't create unused file Andrei Rybak
2023-03-13 21:56 ` Junio C Hamano
2023-03-12 20:15 ` [PATCH v1 7/7] t1507: assert output of rev-parse Andrei Rybak
2023-03-13 22:41 ` [PATCH v1 0/7] t: fix unused files, part 1 Junio C Hamano
2023-03-14 20:43 ` Andrei Rybak
2023-03-18 15:46 ` [PATCH v2 " Andrei Rybak
2023-03-18 15:46 ` [PATCH v2 1/7] t1005: assert output of ls-files Andrei Rybak
2023-03-18 15:46 ` [PATCH v2 2/7] t1006: assert error output of cat-file Andrei Rybak
2023-03-18 15:46 ` [PATCH v2 3/7] t1010: don't create unused files Andrei Rybak
2023-03-18 15:46 ` [PATCH v2 4/7] t1302: don't create unused file Andrei Rybak
2023-03-18 15:46 ` [PATCH v2 5/7] t1400: assert output of update-ref Andrei Rybak
2023-03-18 15:46 ` [PATCH v2 6/7] t1404: don't create unused file Andrei Rybak
2023-03-18 15:46 ` [PATCH v2 7/7] t1507: assert output of rev-parse Andrei Rybak
2023-03-24 20:54 ` [PATCH v3 0/7] t: fix unused files, part 1 Andrei Rybak
2023-03-24 20:54 ` [PATCH v3 1/7] t1005: assert output of ls-files Andrei Rybak
2023-03-24 20:54 ` [PATCH v3 2/7] t1006: assert error output of cat-file Andrei Rybak
2023-03-24 20:54 ` [PATCH v3 3/7] t1010: don't create unused files Andrei Rybak
2023-03-24 20:54 ` [PATCH v3 4/7] t1302: don't create unused file Andrei Rybak
2023-03-24 20:54 ` [PATCH v3 5/7] t1400: assert output of update-ref Andrei Rybak
2023-03-24 20:54 ` [PATCH v3 6/7] t1404: don't create unused file Andrei Rybak
2023-03-24 20:54 ` [PATCH v3 7/7] t1507: assert output of rev-parse Andrei Rybak
2023-03-28 17:37 ` [PATCH v3 0/7] t: fix unused files, part 1 Junio C Hamano
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=xmqqsfe8s56p.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=git@grubix.eu \
--cc=git@vger.kernel.org \
--cc=mhagger@alum.mit.edu \
--cc=peff@peff.net \
--cc=ps@pks.im \
--cc=rybak.a.v@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.