From: Taylor Blau <me@ttaylorr.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Shubham Mishra <shivam828787@gmail.com>,
git@vger.kernel.org, Derrick Stolee <stolee@gmail.com>
Subject: Re: [PATCH 0/2] microproject: avoid using pipes in test
Date: Tue, 22 Feb 2022 14:39:21 -0500 [thread overview]
Message-ID: <YhU76TpyP6p56/oV@nand.local> (raw)
In-Reply-To: <220222.86pmnf6ket.gmgdl@evledraar.gmail.com>
On Tue, Feb 22, 2022 at 03:24:31PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, Feb 22 2022, Shubham Mishra wrote:
>
> > pipes doesn't care about error codes and ignore them thus we should not use them in tests.
>
> Aside from what Derrick Stolee mentioned in his feedback, all of which I
> agree with.
>
> I think these changes are good, but it's not the case that we try to
> avoid using pipes at all in our tests.
>
> It's often a hassle, and just not worth it, e.g.:
>
> oid=$(echo foo | git hash-object --stdin -w) &&
>
> Sure, we can make that:
>
> echo foo >in &&
> oid=$(git hash-object --stdin -w <in) &&
>
> But in the general case it's not worth worrying about.
Agreed, and I would add that we don't necessarily need to worry about
non-Git commands on the left-hand side of a pipe. So something like:
find ... | sort >actual
isn't a problem for us, because our test suite assumes that something
like find will not fail. So leaving instances of those alone is OK,
but...
> What we *do* try to avoid, and what's actually important is to never
> invoke "git" or other programs we invoke on the LHS of a pipe, or to
> otherwise do so in a way that hides potential errors.
>
> That's not isolated to just pipes, but e.g. calling it within helper
> functions that don't &&-chain, but pipes are probably the most common
> offender.
>
> The reason we do that is because in hacking git we may make it error,
> segfault etc. If it's on the LHS of a pipe that failure becomes
> indistinguishable from success.
>
> And if the test is really checking e.g. "when I run git like this, it
> produces no output" printing nothing with an exit of 0 will become the
> same as a segafault for the purposes of test.
...yes, we do care about Git failures. So something like:
git ls-files | grep "want"
would be no-good, since any failures running 'git ls-files' would be
quashed by the pipe.
Thanks,
Taylor
next prev parent reply other threads:[~2022-02-22 19:39 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-22 11:43 [PATCH 0/2] microproject: avoid using pipes in test Shubham Mishra
2022-02-22 11:43 ` [PATCH 1/2] t0001: remove pipes Shubham Mishra
2022-02-22 13:54 ` Derrick Stolee
2022-02-22 18:16 ` Shubham Mishra
2022-02-22 20:32 ` Christian Couder
2022-02-23 21:07 ` Junio C Hamano
2022-02-24 3:28 ` Christian Couder
2022-02-22 11:43 ` [PATCH 2/2] t0003: " Shubham Mishra
2022-02-22 13:50 ` [PATCH 0/2] microproject: avoid using pipes in test Derrick Stolee
2022-02-22 14:24 ` Ævar Arnfjörð Bjarmason
2022-02-22 19:12 ` Shubham Mishra
2022-02-22 19:39 ` Taylor Blau [this message]
2022-02-23 11:53 ` [PATCH v2 0/2] avoid pipes with Git on LHS Shubham Mishra
2022-02-23 11:53 ` [PATCH v2 1/2] t0001: " Shubham Mishra
2022-02-23 17:53 ` Taylor Blau
2022-02-23 18:01 ` Shubham Mishra
2022-02-23 18:02 ` Taylor Blau
2022-02-23 21:10 ` Junio C Hamano
2022-02-24 5:14 ` Shubham Mishra
2022-02-23 11:53 ` [PATCH v2 2/2] t0003: " Shubham Mishra
2022-02-23 17:54 ` Taylor Blau
2022-02-23 19:59 ` Shubham Mishra
2022-02-23 12:08 ` [PATCH v2 0/2] " Shubham Mishra
2022-02-23 13:19 ` Shaoxuan Yuan
2022-02-23 18:01 ` Taylor Blau
2022-02-23 20:04 ` Shubham Mishra
2022-02-24 3:43 ` [PATCH 0/2] microproject: avoid using pipes in test Christian Couder
2022-02-24 5:22 ` Shubham Mishra
2022-02-24 9:29 ` Christian Couder
2022-02-24 10:13 ` Shubham Mishra
2022-02-24 18:22 ` Christian Couder
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YhU76TpyP6p56/oV@nand.local \
--to=me@ttaylorr.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=shivam828787@gmail.com \
--cc=stolee@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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).