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
prev parent 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®