From: Jim Cromie <jcromie@divsol.com>
To: kernel-janitors@vger.kernel.org
Subject: Re: [KJ] RFC - trailing whitespace cleanup script
Date: Mon, 18 Jul 2005 18:03:23 +0000 [thread overview]
Message-ID: <42DBEEEB.4080803@divsol.com> (raw)
In-Reply-To: <42D9C495.2090405@divsol.com>
Jim Cromie wrote:
> Domen, all,
>
> Ive considered running following 1-lineer and submitting per-subsystem
> cleanup patches.
>
> cp -al $tree $tree-clean; perl -pi.bak -e 's/\s+\n//' `find
> $tree-clean -print` > mega-patch
>
I just ran this in a linux-kj directory
egrep -rl '\s$' * | xargs perl -pi -e 's/\s+\n/\n/'
and omygod, it produces 21 MB of unified diffs.
some observations:
60K lines of arch/ diffs
40K lines of Documentation diffs ( not relevant, tb scrapped)
lots of trailing whitespace in comments
hard to programmatically avoid patching.
99% avoided if script tolerates one trailing whitespace.
( ie shrinks diff-file by 75% )
> So, what Id propose is:
>
> a. just prior to releasing rc4-kj, do an rc4-kj-pre
> b. run script against pre tree.
> c. diff -rup pre pre-clean > mega-patch
> d. manually edit/chop up mega-patch on subsystem boundaries
> e. apply each to pre, release rc4-kj
>
given the diff size, this is probably inadequate.
Ive written a script to carve a megapatch into individual chunk-files,
and plan to modify it to carve on a specified directory depth, (ala -pN).
Im familiar with LKML patch submission rules
1. no gzips
2. no tars
3. no mega-patches
4. no patch-frags ( ie reams of tiny patches )
5. use your judgement wrt patch-size, content.
For this list, are the rules the same, slightly different ?
Particularly wrt 5, we're dealing with less/little semantic content,
so can be bigger, esp to avoid 4.
and gzips seems useful, esp for patches with 100k of whitespace.
As an extreme example, I could send to you, privately,
a tarball with thousands of patch frags, and a script to apply them
serially,
and to delete the ones that fail to apply. Youre left with the ones
that did.
> f. repeat periodically
> g. get janitors to recognize that they should do harder fixes, and
> leave whitespace
> for the robo-janitor / whitespace-roomba
>
> BTW
>
> when were kj patches last merged into mainline ?
> how often (on average) does this happen ?
>
also, are you using git ?
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
next prev parent reply other threads:[~2005-07-18 18:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-17 2:38 [KJ] RFC - trailing whitespace cleanup script Jim Cromie
2005-07-18 12:00 ` Ricardo Nabinger Sanchez
2005-07-18 13:09 ` walter harms
2005-07-18 14:44 ` Alexey Dobriyan
2005-07-18 16:11 ` Jim Cromie
2005-07-18 17:06 ` Domen Puncer
2005-07-18 18:03 ` Jim Cromie [this message]
2005-07-18 18:10 ` Jim Cromie
2005-07-18 22:58 ` Alexey Dobriyan
2005-07-22 18:14 ` maximilian attems
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=42DBEEEB.4080803@divsol.com \
--to=jcromie@divsol.com \
--cc=kernel-janitors@vger.kernel.org \
/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.