Am 11.02.2012 10:19, schrieb Blue Swirl: > On Wed, Feb 8, 2012 at 15:36, Andreas Färber <afaer...@suse.de> wrote: >> This is not about whether or not we put a space somewhere. >> >> It's about reviewers and SubmitAPatch telling people to run >> checkpatch.pl on patches and checkpatch.pl reporting this as an ERROR, >> not a WARNING. So if you follow Stefan's instructions on running the >> script as a commit hook (which is the only sane way to run it when >> handling lots of patches) you can't commit a patch or your local changes >> when there are ERRORs. > > The warning levels are from Linux, they could well be incorrect.
My memory tricked me, I must've mixed it up with the other issue I was investigating (too little sleep and very annoyed about the monolithic fragments of Perl source code and checkpatch.pl not conforming to its own rules, e.g. tab indention and > 80 chars). Still, my point remains: what shows up in checkpatch.pl output will get fixed by new contributors, whether WARNING or ERROR. And checkpatch.pl cannot distinguish between changes that correctly update old-style code (e.g., adding braces for if) and code that aims for consistency in a file. Leaving checkpatch.pl unchanged and demanding this special case doesn't go along well and will cause frustration on all sides and reformatting back and forth, something that was declared forbidden elsewhere and patches doing reformattings were turned down. Andreas P.S. For the record, Stefan pointed me to git-commit --no-verify for ignoring checkpatch ERRORs. -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg