linux-kernel - Re: "whitespace coding style cleanup" broke coding style

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F4BD24C.6000307@suse.cz>
Date:	Mon, 27 Feb 2012 19:58:20 +0100
From:	Jiri Slaby <jslaby@...e.cz>
To:	Joe Perches <joe@...ches.com>
CC:	Jiri Slaby <jirislaby@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Hansjoerg Lipp <hjlipp@....de>,
	Tilman Schmidt <tilman@...p.cc>,
	gigaset307x-common@...ts.sourceforge.net
Subject: Re: "whitespace coding style cleanup" broke coding style

On 02/27/2012 06:27 PM, Joe Perches wrote:
> On Mon, 2012-02-27 at 18:12 +0100, Jiri Slaby wrote:
>> The patch should not
>> touch the code at all. It is obviously totally broken. In a separate
>> patch you might do s@,@;@ instead.
>
> The code in either form is neither broken nor
> incorrect.  It's just "out of style".
> Emacs did made it consistent.

I understand that it is correct according to the style. It is not 
correct in that how humans read it.

>> Hmm, but did not we conclude some time ago that we will not touch code
>> just to perform a whitespace cleanup?
>
> It's a prelude to other patches so actually
> that's done quite a lot.   git blame -w
> doesn't even show my name on any of the
> code in this patch.

Yeah, but git merge or rebase do not cope with this. That is the problem 
I am writing about.

>>> It was a first pass and an overall improvement.
>>
>> I hope no other passes are going to happen there or anywhere in TTY
>> drivers. I really do not want to solve zillion collisions in my ~100
>> local patches due to whitespace changes, sorry.
>
> Perhaps you should submit your ~100 patches sooner
> rather than later.  That's a lot of changes that
> could have any number of collisions.

No, sorry, I do not send patch series which are not reviewed by me with 
at least 2 weeks distance. Anyway the point is elsewhere.

To emphasize: I do not mind random changes on random files. That is easy 
to fix. I mind whitespace cleanups over _whole_ subtrees.

>> Yes, but it does not pass our brain, does it? One should throw
>> "checkpatch --file" or alike away, finally.
>
> Perhaps you might notice I did not use checkpatch
> as a guide nor as a criteria for submission.

Ok, but you still fit in "or alike" above.

> It was ~5MB patch btw.  Compilation was done to
> verify lack of object delta only.

I see. Sorry to say that, but 5MB of whitespace cleanup is purely 
insane. Do not tell me that you are going to fix/change something in all 
the files. And even if that is the case, fixes go first so that people 
are able to backport to stable if they fit there.

Please, search archives for similar discussions. I do not want to repeat 
that.

> Thanks for noticing the oddly formatted code.
> I'll send a patch to fix it.

It looks good. ACK. [Although I am sad I will have to solve that 
conflict once more :(.]

thanks,
-- 
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/