mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
To: Joe Perches <joe@perches.com>
Cc: Andy Whitcroft <apw@canonical.com>,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 0/4] checkpatch: improve exit criterias
Date: Tue, 10 Nov 2026 17:58:39 +0000	[thread overview]
Message-ID: <avNbT_IRhemIX_Xw@20e739389ce0> (raw)
In-Reply-To: <42048f8fba5c2726a488b28e94625938bc045f5a.camel@perches.com>

On Tue, Nov 10, 2026 at 06:54:06AM -0800, Joe Perches wrote:
> On Tue, 2026-11-10 at 07:42 -0600, Bjorn Andersson wrote:
> > On Sun, Nov 8, 2026 at 3:04 AM Joe Perches <joe@perches.com> wrote:
> > > 
> > > On Sun, 2026-11-08 at 04:21 +0000, Bjorn Andersson wrote:
> > > > When invoking checkpatch with the --mailback argument over a range of
> > > > patches the tool unexpectedly exits successfully on the first clean
> > > > patch. For example:
> > > > 
> > > >   ./scripts/checkpatch.pl --mailback --git v7.3-rc1..
> > > 
> > > Why is it useful to do this?
> > 
> > My use case is that I create a maintainer branch off e.g. v7.3-rc1
> > (now v7.4-rc1), then apply a bunch of patches and before pushing that
> > out I run "checkpatch.pl --strict v7.3-rc1..".
> 
> I think the description for mailback should be changed to
> be used only for a single commit as this proposal would
> otherwise change the exit condition for the single use case no?
> 

I don't see a problem with the description, but making --mailback reject
cases where multiple inputs are provided sounds like an alternative
solution to save others from being surprised by this.

That said, it's not clear to me why:

  ./scripts/checkpatch.pl --strict --git <hash-with-warnings>

exits with status 1, and:

  ./scripts/checkpatch.pl --strict --mailback --git <hash-with-warnings>

should exit with status 0.

Or why:

 ./scripts/checkpatch.pl --strict --terse -f missing Makefile

exits with status 0 and omits all the warnings from "Makefile".

The intent with my series was indeed to fix "the single use case"... all
four of them.

> > But this is quite noisy, and the compressed "b4 prep --check" output
> > is more what I'm looking for.
> 
> My b4 version is 0.14.3 and the man b4 for prep doesn't include
> a --check option or description so I don't know what that output
> looks like.
> 

It effectively looks git "git log --oneline" mixed with the output of
"checkpatch.pl --terse --no-summary".

> >  So, I borrowed the "checkpatch.pl -q
> > --terse --no-summary --mailback --showfile" from there and it took me
> > a while to realize the difference between:
> > 
> > --mailback                 only produce a report in case of warnings/errors
> > 
> > and "don't produce a report if the first commit is good".
> 
> So perhaps just don't use --mailback?
> 

Of course, I know that now.

> And remove the --showfile so checkpatch adds the git commit id
> to the output and maybe add a front end little script to do
> the git commit id to commit subject to make it easier to detect
> what commit might need updating?

I'm now using "checkpatch.pl --strict --terse --no-summary --git
<range>" and that gives me the compact output I was looking for.

Regards,
Bjorn

      reply	other threads:[~2026-11-10 17:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-08  4:21 Bjorn Andersson
2026-11-08  4:21 ` [PATCH 1/4] checkpatch: don't stop at the first clean patch with --mailback Bjorn Andersson
2026-11-08  4:21 ` [PATCH 2/4] checkpatch: don't stop at the first non-patch input with --no-patch Bjorn Andersson
2026-11-08  4:21 ` [PATCH 3/4] checkpatch: don't stop at the first empty input Bjorn Andersson
2026-11-08  4:21 ` [PATCH 4/4] checkpatch: fail on missing or unreadable files with --file Bjorn Andersson
2026-11-08  9:04 ` [PATCH 0/4] checkpatch: improve exit criterias Joe Perches
2026-11-10 13:42   ` Bjorn Andersson
2026-11-10 14:54     ` Joe Perches
2026-11-10 17:58       ` Bjorn Andersson [this message]

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=avNbT_IRhemIX_Xw@20e739389ce0 \
    --to=bjorn.andersson@oss.qualcomm.com \
    --cc=apw@canonical.com \
    --cc=joe@perches.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®