Agreed.
Thank goodness that all of this is over… ;D
I’m going to resurrect this because there are some easy fixes 
:P.
- Absolute bog-standard convention in the games industry (and in all large-scale dev work I’ve done in mainstream IT industry) uses check-in hooks on the SCM. One of the common ones is “reformat source code”. There is NEVER a reason for you to have “different formatting”-introduced diffs in an SCM: if your SCM is so rubbish that it doesn’t support check-in hooks, you need to come into the 21st century and get a good one ;).
Note: the other really common check-in hook is “run unit tests”, with a refusal to check-in code that fails any of the unit tests. Finding 0 unit tests is sometimes regarded as a failure in its own right, depends how draconian your producer and/or lead programmer is :).
(almost every formatter that plugs in to eclipse and NB has a command-line version designed to be friendly with your SCM)
- Code style is important on an OSS project because it is part of the training of newbie programmers who come to the project probably relatively inexperienced and unskilled, and who benefit from being forced into good conventions early on until they reach the point where they are experienced enough to make their own, informed, decisions on what style(s) to use. All good OSS projects have newbie programmers, this is not a bad thing, it’s a good thing: shows that the project admins are friendly and welcoming, and that in return for their time and code the developers are getting something substantial back (training, effectively, even if it is largely self-taught).
@ENC and blah
Please stop influencing a (maybe) fundamental discussion about a project you’ve never worked on and with which’s code you’ve never been confronted. Correct me if I’m wrong.