[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