linux-ext4 - Re: [PATCH v2] ext4: inode: Delete braces for single statements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAPXz4EPuy6ozucoWtFtdC3j_DCeCZ-gWm1zE+tKLVzAmskyR7w@mail.gmail.com>
Date: Thu, 17 Oct 2024 17:50:25 -0700
From: Nicolas Bretz <bretznic@...il.com>
To: "Theodore Ts'o" <tytso@....edu>
Cc: linux-ext4@...r.kernel.org
Subject: Re: [PATCH v2] ext4: inode: Delete braces for single statements

On Thu, Oct 17, 2024 at 5:19 PM Theodore Ts'o <tytso@....edu> wrote:
>
> On Mon, Oct 14, 2024 at 07:06:54AM -0700, Nicolas Bretz wrote:
> > checkpatch.pl warnings - braces are not necessary
> >
> > Signed-off-by: Nicolas Bretz <bretznic@...il.com>
>
> The checkpatch.pl script is meant to check *patches*, and in general,
> in the ext4 subsystem (as with many other subststems) patches which
> only fix checkpatch.pl file are discouraged, since it can introduce
> potential patch conflicts when cherrypicking fixes, or in the course
> of other people doing other development.
>
> Granted, dealing with the patch conflicts aren't that hard, but the
> cost/benefit ratio isn't worth it.  For kernel newbies who are looking
> for practice submitting patches, cleaning up checkpatch warnings in
> the staging subsystem are fine, but in general, it's best to not send
> cleanup-only patches to other parts of the system.
>
> Of course, if you're modifying that part of the code in question,
> that's a perfect time to clean it up while you're at it.
>
> > Removed trailing whitespaces introduced in v1
>
> In the future, please put changes between the v1 and v2 patches after
> the three hyphens (by where the summary of how many lines were added
> or removed in each file).  That way the description of changes between
> earlier versions aren't preserved forever in the git commit
> description, since they aren't really useful once they've landed in
> the git.
>
> Thanks,
>
>                                         - Ted

Noted, I appreciate the input.