git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Michael J Gruber <git@grubix.eu>,
	git@vger.kernel.org, Phillip Wood <phillip.wood123@gmail.com>,
	Derrick Stolee <derrickstolee@github.com>
Subject: Re: [PATCH] t3070: make chain lint tester happy
Date: Sat, 25 Mar 2023 04:41:07 -0400	[thread overview]
Message-ID: <20230325084107.GB3738217@coredump.intra.peff.net> (raw)
In-Reply-To: <CAPig+cTBwAugUL_u_SPebFRj4j1Gv6FMuH8vn+uUy=6_+GXy3A@mail.gmail.com>

On Sat, Mar 25, 2023 at 04:18:54AM -0400, Eric Sunshine wrote:

> >   1. Say that the internal linter still has value, and tweak the
> >      suppression so it only turns off the extra per-script run of
> >      chainlint.pl, and not the internal one (which is cheap-ish to run).
> 
> This is appealing since the internal linter is nearly zero-cost,
> though doing this would not fully address the "recipe for confusion"
> since the two linters would still not be in agreement. This approach
> does have the benefit that it gives at least _some_ protection (minus
> caveats mentioned below) on platforms where it may be common to
> disable chainlint.pl due to slowness, such as Windows.

I think it's OK if they're not in agreement, as long as both are run.
Then the set of problems you need to fix is the union of their outputs.
That's conservative, but everybody gets the same answer.

The bigger confusion to me is when "make test" and "./t1234-foo.sh" do
not agree in their output, which is what happened here. Some people say
"everything is good" and some say "no, it is broken", depending on how
they ran it.

> >   2. Say that the internal linter does not have value, and we should
> >      rely on chainlint.pl. In which case we might as well ditch the
> >      internal one completely.
> 
> The value of the internal linter is fairly limited in that it only
> checks top-level &&-chain; it doesn't check inside subprocesses,
> blocks, or any compound statement (case/esac, if/fi, while/done,
> etc.).

Right, the chainlint.pl one is much more thorough. I just wondered if
there were any cases we were worried about it missing, that the internal
one catches. We found one in this thread, but as discussed, it is not a
problem (presumably chainlint.pl catches a "real" case where an
earlier line is hidden by the "&", but I wouldn't mind seeing it
complain here as a matter of style/future-proofing).

> I retained the internal linter in place "just in case" (i.e. in the
> event the script missed something legitimate), but I don't feel
> strongly about it.

Certainly the output from chainlint.pl is much nicer, too. :) I think
I'd be comfortable dropping the internal one at this point in terms of
quality. The bigger question to me is whether there are setups where it
isn't run (you mentioned Windows, but I'd have thought the
single-process invocation made things nice and fast there).

-Peff

  reply	other threads:[~2023-03-25  8:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-20 16:09 [PATCH 0/3] wildmatch: fix exponential behavior Phillip Wood
2023-03-20 16:10 ` [PATCH 1/3] " Phillip Wood
2023-03-24 22:17   ` [PATCH] t3070: make chain lint tester happy Michael J Gruber
2023-03-25  6:37     ` Jeff King
2023-03-25  6:54       ` Eric Sunshine
2023-03-25  7:58         ` Jeff King
2023-03-25  8:04           ` Jeff King
2023-03-25  8:18             ` Eric Sunshine
2023-03-25  8:41               ` Jeff King [this message]
2023-03-25  8:51                 ` Jeff King
2023-03-25  9:09                   ` Eric Sunshine
2023-03-25 19:47                     ` Jeff King
2023-03-25  9:17                 ` Eric Sunshine
2023-03-26 14:30             ` Phillip Wood
2023-03-26 14:54               ` Michael J Gruber
2023-03-25  8:06           ` Eric Sunshine
2023-03-25  8:36             ` Jeff King
2023-03-20 16:10 ` [PATCH 2/3] wildmatch: avoid undefined behavior Phillip Wood
2023-03-20 16:10 ` [PATCH 3/3] wildmatch: hide internal return values Phillip Wood
2023-03-20 17:58 ` [PATCH 0/3] wildmatch: fix exponential behavior Junio C Hamano
2023-03-23 14:19 ` Derrick Stolee
2023-03-24 14:04   ` Phillip Wood

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=20230325084107.GB3738217@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=derrickstolee@github.com \
    --cc=git@grubix.eu \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood123@gmail.com \
    --cc=sunshine@sunshineco.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).