Re: [Ksummit-discuss] [CORE TOPIC] checkpatch/Codingstyle and trivial patch spam

[Julia Lawall <julia.lawall@lip6.fr>]

On Tue, 13 Sep 2016, Joe Perches wrote:

> On Tue, 2016-09-13 at 14:03 -0600, Jonathan Corbet wrote:
> > On Tue, 13 Sep 2016 12:45:20 -0700 Josh Triplett <josh@joshtriplett.org> wrote:
> > > On Tue, Sep 13, 2016 at 08:58:49PM +0200, Christian Borntraeger wrote:
> > > > 3. CodingStyle seems to get changes which have no ACK or Reviewed-by that seem
> > > > to be controversial.  e.g.
> > > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=865a1caa4b6b886babdd9d67e7c3608be4567a51
> > > > suggested to indent labels with a space, and was then immediately followed by
> > > > patches. Is there a process in place to verify and challenge such changes?
> > > Ideally, that should come up during review of the CodingStyle patch.
> > > Changes shouldn't go into CodingStyle except to document existing
> > > process and unwritten rules, or to document the results of a discussion
> > > and consensus.  That particular change to CodingStyle should have been
> > > rejected, and should be reverted.
> >
> >
> >
> >
> > So I'm quite reluctant to take CodingStyle patches for just this reason;
> > *I* certainly don't want to be the one dictating style for the kernel, but
> > I'm not really sure who does.
> []
> > (FWIW, I'm not really sure how I came to take the one mentioned above, I
> > guess I was having a bad day.  The space-before-label rule strikes me as
> > strange at best...)
>
> The space-before-label rule should be removed.
>
> It's a silly work-around rule for those that don't like
> to see labels in a diff instead of a function name.
>
> A new .gitattributes patch from Jean Delvare fixes that.
>
> References:
>
> https://lkml.org/lkml/2011/8/29/410
> https://lkml.org/lkml/2016/9/6/445
> https://lkml.org/lkml/2016/9/7/316

Having git log etc do the right thing is really useful if one wants to
analyze patches.  I hope that there will be the right behavior with no
effort on the part of the user as soon as possible.

julia