My editors are configured to remove trailing spaces (this is useful for removing artifacts of indentation). The flip side of this is that my patches sometimes contain unrelated trailing spaces fixes.

Trailing spaces are not significant in any CPython source file, their presence I believe mistake. Easier once we remove all spaces and then prevent the appearance of new, than constantly face to unrelated changes. I'm not attaching a patch (it is too big, over 5 MB), anyone can create it by the following commands:

    hg status -cn | tr '\n' '\0' | xargs -0 sed -i -re 's/[ \t]+$//'

It would be good if the Mercurial would had hook, which automatically remove trailing spaces or prohibit to commit patches that contain trailing spaces.

Because CPython repository contains binary files too, they should be reverted:

    hg diff | sed -nre 's/^Binary file (.*) has changed/\1/p' | tr '\n' '\0' | xargs -0 hg revert

There already is a hook in place for the main python.org repository that checks for and rejects changesets that include files with space issues:

http://hg.python.org/hooks/file/bd04c6b37749/checkwhitespace.py

You can add it to your local repo to check patches before they are pushed.

Or you can use "make patchcheck" which will (hopefully) warn you of such issues.

> There already is a hook in place for the main python.org repository that checks for and rejects changesets that include files with space issues:

If there is already a hook, then why do some files have spurious white space (i.e. at the end of a line)?  Is that because those issues were present prior to putting the hook in place?

AFAIR the hook only applies to Python and reST files, not C files.
I think Georg wrote it, perhaps he knows the reasons.

> There already is a hook in place for the main python.org repository that
> checks for and rejects changesets that include files with space issues:

Now I understand why there is no problem with .py files. But there are a lot of 
other files (including .c and .h) with trailing whitespaces.

Well, I'm -0 on extending the hook to C files.

I found a few files where trailing spaces are significant (patches, RTF, test data). Excluding them and three generated file (Unicode data, generating scripts should be smarter), I divided the remaining into several parts:

1) the libffi library;
2) the libmpdec library;
3) other C sources;
4) the rest of the files (mainly readme-like files and build scripts).

-1 for making wholesale whitespace changes. It potentially makes merging harder for little benefit. Imported files from other projects should definitely not be touched. IMO, the only thing potentially worth considering is extending the existing hook to C files.  I'm +0 on that myself.

I'm not against whitespace cleanup every now and then, but also -0
on a hook for C files. I think that (for C) the annoyance of having
a patch rejected because of trailing whitespace outweighs the
overall benefit.

How is it more of a nuisance for C files than for .py files?
Editor 'trim trailing' tools certainly don't care.

Out of curiosity, is there a mechanism to bypass the hook on a per-file basis, if necessary?  FWIW, the WebKit open source project had a similar hook (for SVN) to prevent the inclusion of tabs in source files, and a custom SVN property was used to bypass the check on a per-file basis.

Since we've established that python files are already covered by 'make patchcheck' and the hg checkin hook and that there does not appear to be much enthusiasm for extending the hook to C files or to wholesale whitespace cleanup, the remaining issue is whether to extend 'make patchcheck' for C files. And that is the subject of open Issue8912.  So I'm going to close this issue as a duplicate of that one and suggest further discussion take place there.  As for a per-file bypass, I'm not aware of any nor of any need that has arisen so far for one.