On Fri, 27 Nov 2009, Richard Earnshaw wrote: > On Fri, 2009-11-27 at 09:40 -0500, Joern Rennecke wrote: > > Quoting Richard Earnshaw <rearn...@arm.com>: > > > An SVN pre-commit filter (default on, disabled by SVN attribute if > > > needed) should instead just reject files that have trailing white space. > > > > I think a better mechanism to deal with exceptions is to have a property > > that describes the current misformatting (or unusual formatting for some > > test cases / Makefiles). I.e. if a file is known to have N lines with > > trailing whitespace, M with spaces-for-tabs, K with > > spaces-hidden-in-front-of-tabs, and L with carriage return, a patch will > > be rejected if it increases N, M, K or L. If it decreases it, the count > > property can be auto-adjusted to prevent regressions. And if you really > > have to, you can adjust a property by hand before checking in a patch > > that increases one of the counts. > > Sounds like unnecessary over-engineering to me. 99% of files should > have no trailing white space. The few that do probably have it for some > good reason and policing this by explicit count is most likely > pointless.
Indeed, the obvious way to filter would be to disallow converting a file with "good" formatting into one with "bad" formatting, or adding new files with "bad" formatting, on trunk, with some general patterns for exceptions (binary files, generated files that bring in text from outside the GCC sources, etc.). If you need to commit a new file with bad formatting, edit the hooks before and after (or just before if it can be described by a new general pattern). If a file already has "bad" formatting, the hook wouldn't check changes to it (it would be possible to have multiple notions of "bad", each checked independently). -- Joseph S. Myers jos...@codesourcery.com
