From: Junio C Hamano <gitster@pobox.com>
To: Anthony Wang <anthonywang513@gmail.com>
Cc: anthonywang03@icloud.com, christian.couder@gmail.com,
git@vger.kernel.org, karthik.188@gmail.com, ps@pks.im,
shejialuo@gmail.com, shyamthakkar001@gmail.com
Subject: Re: [GSoC] [PATCH v2 1/3] t9811: avoid using pipes to expose exit codes
Date: Tue, 08 Apr 2025 00:17:01 +0000 [thread overview]
Message-ID: <xmqqtt6zjyma.fsf@gitster.g> (raw)
In-Reply-To: <20250407212834.53183-1-anthonywang03@icloud.com> (Anthony Wang's message of "Mon, 7 Apr 2025 23:28:34 +0200")
Anthony Wang <anthonywang513@gmail.com> writes:
>> If so, instead of grepping around, we should be testing that in a
>> more direct way, perhaps with something like
>>
>> git show-ref --verify refs/tags/TAG_F1_1 &&
>> git show-ref --verify refs/tags/TAG_F1_2 &&
>> test_must_fail git show-ref --verify refs/tags/TAG_F1_ONLY &&
>>
>> no?
>>
>
> Possibly, but I believe adding the test_must_fail check would be modifying
> the original intent of the test, as it would pass even with the existence of
> TAG_F1_ONLY. However, if we are only performing actions to cause TAG_F1_1
> and TAG_F1_2 to exist, then it would be an issue if TAG_F1_ONLY existed.
I view it a bit differently.
Use of "grep" over the output of "git tag" is simply a sloppy
programming. If the test wanted to verify "TAG_F1_1 exists", it
shouldn't have grepped for TAG_F1_1, because another tag T_TAG_F1_1
would produce a false positive hit if the earlier test gets updated.
Similarly, not verifying what should not exist is being sloppy.
People who come up with a new feature (in this case, "git p4 sync"
involving tags) tend to test positive effects to show how their
shiny new toy does things, and forgets to test lack of effects to
ensure that their shiny new toy does *not* do what they should not
do.
If the original test were written solidly and use of pipe hiding
exit code were the only problem it had, I would agree that making
minimum change should be preferrable, but the original test seems to
be so sloppy in this case.
Thanks.
next prev parent reply other threads:[~2025-04-08 0:17 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-05 10:37 [GSoC] [PATCH 1/1] t9811: avoid using pipes Anthony Wang
2025-04-07 7:51 ` Patrick Steinhardt
2025-04-07 11:18 ` [GSoC] [PATCH v2 0/3] t9811: Improve test coverage and clarity Anthony Wang
2025-04-07 11:18 ` [GSoC] [PATCH v2 1/3] t9811: avoid using pipes to expose exit codes Anthony Wang
2025-04-07 16:17 ` Eric Sunshine
2025-04-07 17:19 ` Junio C Hamano
2025-04-07 21:28 ` Anthony Wang
2025-04-08 0:17 ` Junio C Hamano [this message]
2025-04-08 7:35 ` Anthony Wang
2025-04-07 11:18 ` [GSoC] [PATCH v2 2/3] t9811: Remove the -q quiet mode from some instances of grep Anthony Wang
2025-04-07 16:26 ` Eric Sunshine
2025-04-07 22:11 ` Junio C Hamano
2025-04-07 11:18 ` [GSoC] [PATCH v2 3/3] t9811: Change `grep` to `test_grep` for debug output Anthony Wang
2025-04-07 17:25 ` [GSoC] [PATCH v3 0/3] t9811: Improve test coverage and clarity Anthony Wang
2025-04-07 17:25 ` [GSoC] [PATCH v3 1/3] t9811: avoid using pipes to expose exit codes Anthony Wang
2025-04-07 17:25 ` [GSoC] [PATCH v3 2/3] t9811: Remove the -q quiet mode from some instances of grep Anthony Wang
2025-04-07 17:25 ` [GSoC] [PATCH v3 3/3] t9811: Change `grep` to `test_grep` for debug output Anthony Wang
2025-04-08 8:08 ` [GSoC] [PATCH v4 0/1] t9811: Improve test coverage and clarity Anthony Wang
2025-04-08 8:08 ` [GSoC] [PATCH v4 1/1] Remove the pipe following the `git tag`, ensuring the exit code is not hidden. Add explicit verification to check for expected and unexpected tags, increasing specificity and future-proofing a portion of the test Anthony Wang
2025-04-08 9:55 ` Karthik Nayak
2025-04-08 11:48 ` [GSoC] [PATCH v5 0/1] t9811: Improve test coverage and clarity Anthony Wang
2025-04-08 11:48 ` [GSoC] [PATCH v5 1/1] " Anthony Wang
2025-04-08 21:21 ` Junio C Hamano
2025-04-08 21:28 ` Eric Sunshine
2025-04-09 8:15 ` Anthony Wang
2025-04-09 13:29 ` Junio C Hamano
2025-04-12 6:19 ` [GSoC] [PATCH v6 0/1] t9811: be more precise to check importing of tags Anthony Wang
2025-04-12 6:19 ` [GSoC] [PATCH v6 1/1] " Anthony Wang
2025-04-15 14:55 ` Junio C Hamano
2025-04-16 15:03 ` Anthony Wang
2025-04-16 14:59 ` [GSoC] [PATCH v7 0/1] " Anthony Wang
2025-04-16 14:59 ` [GSoC] [PATCH v7 1/1] " Anthony Wang
2025-04-18 18:12 ` Junio C Hamano
2025-04-18 21:03 ` Junio C Hamano
2025-04-18 21:41 ` Eric Sunshine
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=xmqqtt6zjyma.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=anthonywang03@icloud.com \
--cc=anthonywang513@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=karthik.188@gmail.com \
--cc=ps@pks.im \
--cc=shejialuo@gmail.com \
--cc=shyamthakkar001@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).