From: Junio C Hamano <gitster@pobox.com>
To: Siddharth Shrimali <r.siddharth.shrimali@gmail.com>
Cc: git@vger.kernel.org, peff@peff.net
Subject: Re: [PATCH] t3700: avoid suppressing git's exit code
Date: Fri, 27 Feb 2026 10:19:48 -0800 [thread overview]
Message-ID: <xmqqv7fiqcaj.fsf@gitster.g> (raw)
In-Reply-To: <20260227165143.70188-1-r.siddharth.shrimali@gmail.com> (Siddharth Shrimali's message of "Fri, 27 Feb 2026 22:21:43 +0530")
Siddharth Shrimali <r.siddharth.shrimali@gmail.com> writes:
> When piping the output of git ls-files into grep, the exit code of
> git ls-files is suppressed.
>
> Avoid this by redirecting the output of git ls-files to a file and
> then running grep on that file. This ensures that any crash in
> git ls-files will be caught by the test suite.
>
> Signed-off-by: Siddharth Shrimali <r.siddharth.shrimali@gmail.com>
> ---
> t/t3700-add.sh | 38 +++++++++++++++++++++++---------------
> 1 file changed, 23 insertions(+), 15 deletions(-)
A few things that I noticed.
* If "git foo | grep bar" was expecting to hide exit code from
"git" and check the output (e.g., "git diff --exit-code | grep foo"),
a mechanical conversion "git diff --exit-code >out && grep foo out"
would change the meaning of the test and break it. I did not check
if this patch has such an unintended breakage, though.
* Many of them do this:
> - git ls-files foo | grep foo
> + git ls-files foo >actual &&
> + grep foo <actual
or this
> - ! ( git ls-files foo1 | grep foo1 )
> + git ls-files foo1 >actual &&
> + ! grep foo1 actual
in which we might consider using "test_grep" (and "test_grep !")
to help the developer who wants to debug a breakage in ls-files
by highlighting what is unexpected in the output in their broken
version.
* A rewrite like this may want to be further broken down.
> - test $(git ls-files --stage | grep ^100644 | wc -l) -eq 0 &&
> + test $(git ls-files --stage >actual && grep ^100644 actual | wc -l) -eq 0 &&
If "ls-files --stage" segfaults, "grep | wc" would not run, $()
may exit with non-zero and turn into an empty string, but the
final error diagnosis would be something unfathonable like
test: -eq unary operator expected
test: missing argument after '0'
which would not help the person debugging the test very much.
next prev parent reply other threads:[~2026-02-27 18:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-27 16:51 [PATCH] t3700: avoid suppressing git's exit code Siddharth Shrimali
2026-02-27 18:19 ` Junio C Hamano [this message]
2026-02-28 7:00 ` [PATCH v2] t3700: avoid hidden failures and use test_grep helper Siddharth Shrimali
2026-03-02 21:24 ` Junio C Hamano
2026-02-28 8:12 ` [PATCH] t3700: avoid suppressing git's exit code Johannes Sixt
2026-02-28 10:15 ` Siddharth Shrimali
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=xmqqv7fiqcaj.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=r.siddharth.shrimali@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.