From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Jacopo Notarstefano <jacopo.notarstefano@gmail.com>,
Git Mailing List <git@vger.kernel.org>,
Michael Haggerty <mhagger@alum.mit.edu>
Subject: Re: [GSoC14][RFC] Is there any interest in adding a port of checkpatch.pl to contrib/?
Date: Tue, 18 Mar 2014 12:39:42 -0700 [thread overview]
Message-ID: <xmqqa9cn8fep.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAPig+cQPZrHf_Bm_s_qmP6nX2dKcFNi+EUKoPObXHn1novuaHw@mail.gmail.com> (Eric Sunshine's message of "Tue, 18 Mar 2014 00:40:13 -0400")
Eric Sunshine <sunshine@sunshineco.com> writes:
>> 1. Git style guidelines are somewhat different and less strict than
>> their Linux equivalents.
>
> Are checkpatch.pl's customization options, such as --ignore,
> insufficient to make it behave in the desired fashion for git?
If we are to officially encourage the use of checkpatch.pl, we
should stress that mechanically adhering to its check is *not* the
goal. As long as people view it as a tool to _help_ them spot
obvious problems before sending their patches out, but the final
responsibility to produce readable code is upon themselves, not the
script, I am personally fine. Oftentimes we find an occasional long
line that is slightly longer than 80-column limit a lot easier to
read than chopping it artificially in the middle, for example.
>> 2. Several patch threads bounce back and forth because of style fixes.
>> A checkpatch script added as a hook could help reduce these and use
>> more efficiently our time.
>> 3. As far as I can tell, checkpatch needs to be run from the root
>> folder of a linux repository clone. Cloning several hundred MBs for a
>> single perl script looks a little foolish to me.
>
> No need to clone the kernel. checkpatch.pl runs fine standalone with
> the --no-tree option.
>
>> So, is there any interest in adding a port of checkpatch.pl to
>> contrib/?
Not really. Maintaining the forked version is an additional pain we
do not necessarily need. Are we going to carry a port of gcc and
others?
I would rather prefer to add a paragraph in CodingGuidelines that
points at the canonical location to obtain the script, e.g.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl
and a procedure to run the script over their patch. I am too lazy
to check myself, but there must be somewhere we mention the use of
format-patch and send-email in the document, and use of the script
to check would fall naturally between these two steps, I would
think.
next prev parent reply other threads:[~2014-03-18 19:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-18 1:38 [GSoC14][RFC] Is there any interest in adding a port of checkpatch.pl to contrib/? Jacopo Notarstefano
2014-03-18 4:40 ` Eric Sunshine
2014-03-18 19:39 ` Junio C Hamano [this message]
2014-03-18 19:29 ` Junio C Hamano
2014-03-18 23:53 ` Jacopo Notarstefano
2014-03-19 8:40 ` demerphq
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=xmqqa9cn8fep.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jacopo.notarstefano@gmail.com \
--cc=mhagger@alum.mit.edu \
--cc=sunshine@sunshineco.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.