Tom Hobbs wrote:
Okay, I get it. I think.
A mass re-formating of the entire source is definitely a waste of time
and effort.
I agree.
So does the following scenario meet this standard?
- I want to make a meaningful change to Class A.
- Class A is badly formatted.
- I fix the formatting of Class A.
- I commit Class A.
- I make my meaningful change to Class A.
- I commit Class A.
The above process has served me well in the past.
I think this is a good process with one small change. During debug, I
sometimes have to keep visiting and studying a class that is not
necessarily the root cause of the bug. I would like to have the option of:
- I need to study Class A.
- Class A is badly formatted.
- I fix the formatting of Class A.
- I commit Class A.
- I make my meaningful change to Class B.
- I commit Class B.
In other words, don't go looking for classes to reformat, but if you
trip over a badly formatted class that is getting in the way, reformat
and commit it.
I do think general reformatting of a complete class should be a separate
commit, clearly labeled as reformatting.
On Thu, Dec 9, 2010 at 9:44 AM, Sim IJskes - QCG <[email protected]> wrote:
On 12/09/2010 10:34 AM, Tom Hobbs wrote:
Standard no reformatting only commits.
That, when I come across a poorly formated source file (or which there
are many) I can't do a reformat and commit? (And here I'm talking
about more than just tabs vs spaces). If so, I think that's possibly
a mistake, committing reformatting changes at that same time as
meaningful code changes can make reading a diff much harder.
Maybe better phrased is: By default no reformatting-only contributions.
What is necessary is necessary. So if you fix something but want to fix the
layout first locally, please go ahead.
Gr. Sim
