[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1473897909.32273.57.camel@perches.com>
Date: Wed, 14 Sep 2016 17:05:09 -0700
From: Joe Perches <joe@...ches.com>
To: Josh Triplett <josh@...htriplett.org>,
Christian Borntraeger <borntraeger@...ibm.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Andy Whitcroft <apw@...onical.com>, Greg KH <greg@...ah.com>,
Jonathan Corbet <corbet@....net>,
Theodore Ts'o <tytso@....edu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] checkpatch: Minimize checkpatch induced patches...
On Wed, 2016-09-14 at 16:54 -0700, Josh Triplett wrote:
> On Wed, Sep 14, 2016 at 07:56:55PM +0200, Christian Borntraeger wrote:
> > On 09/14/2016 07:51 PM, Joe Perches wrote:
> > > checkpatch can be a useful tool for patches.
> > >
> > > It can be a much more controversial tool when used on files with the
> > > -f option for style and whitespace changes for code that is relatively
> > > stable, obsolete, or for maintained by specific individuals.
[]
> > This will certainly help to reduce the noise. On the other hand I remember Linus
> > saying something along the line that he does not like the -f parameter (and he
> > prefers to set this automatically). So while I like the approach I am not happy
> > enough to ack right now - still looking for a better alternative :-/
> This seems entirely compatible with autodetection. If checkpatch
> detects that it runs on a file rather than a patch, it can assume -f.
> It can then apply this same logic to reject that if 1) in a kernel tree
> and 2) running on a non-staging file and 3) not passed --force.
checkpatch doesn't do autodetection and there's no real
need for it to do it either. The reason is in the name.
get_maintainer does.
Powered by blists - more mailing lists