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
| ||
|
Message-ID: <20190406011858.GJ2217@ZenIV.linux.org.uk> Date: Sat, 6 Apr 2019 02:18:59 +0100 From: Al Viro <viro@...iv.linux.org.uk> To: Radostin Stoyanov <rstoyanov1@...il.com> Cc: luisbg@...nel.org, clm@...com, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, linux-btrfs@...r.kernel.org, linux-aio@...ck.org Subject: Re: [PATCH] fs: remove trailing whitespace On Sat, Apr 06, 2019 at 01:07:23AM +0100, Radostin Stoyanov wrote: > $ cd fs/ > $ find . -type f -exec sed --in-place 's/[[:space:]]\+$//' {} \+ > > Signed-off-by: Radostin Stoyanov <rstoyanov1@...il.com> No. That's not the way to do that kind of stuff. First, how it should be done (and that really belongs somewhere in Documentation/): after having convinced Linus that mechanical change in question needs to happen, you ask him to run the script in question just before the -rc1 of the next cycle. Reason for _not_ doing it as you have: you are creating a pile of conflicts with any number of development branches in various trees, for no good reason. It's a bloody bad idea, especially for something this trivial. What's more, some of those (and the most heavily affected ones) bear rather interesting comments: * This translation table was generated automatically, the * original table can be download from the Microsoft website. * (http://www.microsoft.com/typography/unicode/unicodecp.htm) _If_ it's autogenerated, I'd suggest leaving it alone, or modifying whatever tool has been used to produce the damn thing. FWIW, the situation might be even more unpleasant - URL in the comment is stale. Finding the source actually used is not trivial - poking on archive.org gives multiple versions of the data that comment probably refers to. It would be nice to straighten that mess - as it is, we are probably not stepping into the section 3 there, but "the arrays below had been produced by some tool (not included) from some version(s) of the tables once reachable via links on now-defunct webpage at $URL" is not a good situation, even if nobody really gives a damn about those tables...
Powered by blists - more mailing lists