Eric Sunshine <> writes:

>> 1. Git style guidelines are somewhat different and less strict than
>> their Linux equivalents.
> Are'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, 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. runs fine standalone with
> the --no-tree option.
>> So, is there any interest in adding a port of 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

I would rather prefer to add a paragraph in CodingGuidelines that
points at the canonical location to obtain the script, e.g.

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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to