[MERGE] Less bazaar coding style regressions.
Marius Kruger
amanic at gmail.com
Mon Dec 8 18:56:12 GMT 2008
2008/12/8 Martin Pool <mbp at canonical.com>
> On Sun, Jul 27, 2008 at 6:19 AM, John Arbash Meinel
> <john at arbash-meinel.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Marius Kruger wrote:
> > | Thats right folks,
> > | I think I've successfully written a test which checks for bazaar code
> > | style regressions in the not-yet-commited changes of the working tree
> > | being tested.
> > | Currently I check all newly modified .py files for:
> > | * new trailing white space
> > | * new leading tabs
> > | * new long lines (give warning only)
> > | * no newline at end of files
> > |
> > | It already came in usefull while preparing this patch
> > | ./bzr --no-plugins selftest coding_style
> > | will help people like me to easily prepare non-style-regressing
> patches.
>
> That's pretty cool.
yeay
> Like John, I think I'd prefer this be done in test_source
thats done in the latest patch
> and check
> the whole working tree, except for things that are specifically
> excluded, such as copied-in library source. Then there's no chance of
> missing things that are committed without checking them. If there are
> already things that would fail, let's just fix them up.
Uhm, last time I checked, the bazaar source is riddled with trailing white
space, try:
bzr.dev>$ find -iname "*.py" | xargs grep -n -e ".* $" |wc -l
3319
People have tried to remove it previously, but got it shot down. See eg:
http://www.nabble.com/-MERGE--whitespace-normalization-td18634412.html
So My plan for now was to just *not* allow the situation to regress (which
might in itself prove too painful).
regards
marius
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20081208/d6c413ff/attachment.htm
More information about the bazaar
mailing list