Lately there have been several hints that people are annoyed by commits consisting only of style changes (rearranging imports, "cleaning up" indents) etc.
Of course, there are always good intentions behind such changes, but IMHO changes which make no difference to the actual code, are:
a) risky, because every time one edits a file there's a small risk of making a change to the code without meaning it
b) a waste of our collective energy, as (hopefully) many of us are regularly scanning CVS diff mails, and if it's just to find out that two brackets have been moved it's not very useful.
I have three suggestions:
1) As a general rule, we should refrain from making such changes to our code, unless there is a good reason (code change for example) to edit the file in question.
+1 on condition [a], below
2) When editing a file for a good reason, we should look for such "style" problems and fix them at the same time, or as a separate commit, but before testing our changes.
+1 as a separate commit, per Joerg's message about "losing" changes. Then again, the commit message should clearly say what is going on.
3) We should not change the indentation / code writing style (brackets etc.) of a file when making a minor change to it.
+.75, what consists of a minor change? Little one-line bugfixes?
The idea is to keep the flow of CVS diff messages as low as possible, to save our neuronal bandwidth for more important things than the placement of brackets or the order of imports.
WDYT?
At first I was a little dumbfounded by the proposition, but now that I think of it, it makes more sense, especially for people who are either getting paid to work on Cocoon full-time, or people who are taking time out of their busy day to contribute to the project when they could be earning money in other ways (i.e. consulting).
My condition [a] on the item above was that we should try to eliminate people from having to make these code changes in the first place. We should be following the standard Java style, and most IDEs can help enforce this.
Likewise, we could also make a run through all our code with something as a once-over to fix most of the problems and then "highly encourage" people to follow the Java style guidelines. I know it's probably micromanaging people by enforcing a code convention, but I would also like to argue that readable code which is consistently formatted is easier to read (and maintain), and thus costs less time than wasting scanning CVS commit messages for code which was reformatted. Remember, a lot of work goes into maintaining a project than actually creating new stuff.
Is it possible to fit a code reformatting filter between our cvs commit and the repository?
-Bertrand
Tony
