> > Personally, I'm quite OK with reviewing whitespace-only cosmetic patches to
> > that
> > file, as long as they are in separate commits.
> I think that is a good approach for any program.
> Whitespaces fixes that clean up the code are useful,
> but it's better to keep them separate from other changes.
Our project-wide preference is the other way around: we ask
contributors not to make any whitespace changes except where they
actually change code, or nearby.
I wouldn't call it "the other way around". The two preferences
are close in spirit, in that they both advise against whitespace
changes unrelated or far from the places where the program's
syntax tree was changed. In both cases, intelligible history
is more easily preserved.
It's just that my (and seemingly Richard's) preference is a little more
lax. If something is definitely off cosmetically (say, very long lines
or misleadingly hard to read indentation), then a separate commit
that targets those cosmetics shortcomings is acceptable.
João