All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  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.