On 11/25/09 12:33, Richard Guenther wrote:
On Wed, 25 Nov 2009, Dave Korn wrote:
Joseph S. Myers wrote:
Doing it right at the end of branch-to-trunk merges for a release (which
is where we are right now, just after merges from Graphite) is probably
the optimal timing in terms of minimising the amount of branches that will
need fixing up. The problem is doing it without warning or consensus.
Yep. Given that, maybe we should make a global whitespace cleanup an
official part of the release branching process? It would be nice to keep it
from all building up again, and we could avoid the pain if it was regular and
predictable.
What is the _point_ in doing this? Is there _any_ positive effect
of removing trailing whitespace? Does it looks like there are no bugs to
fix in gcc so that the pointless task of removing trailing whitespace
looks appealing??
I agree there is little value in removing the trailing whitespace. It
makes reviewing changes marginally easier when you don't have to wade
through gratutious whitespace changes.
Ultimately I think there are X issues here.
1. What to do in the immediate term with the repo. I've got no
strong opinions here.
2. What to do longer term. I'd like to see us fix the whitespace
stuff then use hooks or a cron job to make sure they don't come back
again in the future.
3. What is a suitable consequence for this gaffe by HJ?
Jeff
