[MERGE] whitespace normalization

[Andrew Bennetts]

Ben Finney wrote:
> Aaron Bentley <aaron at aaronbentley.com> writes:
> 
> > Aaron Bentley has voted reject.
> > Status is now: Vetoed
> > Comment:
> > Changes like this cause spurious conflicts.
> 
> As do differences between files caused by *not* normalising the
> whitespace in the code base.

Do you have any evidence that this has happened to people working on bzr?  I
certainly don't recall encountering this myself, so I think your concern is
hypothetical.  Maybe there's something different about how other people work
that I'm not aware of?

However, doing a large change like this *will* cause conflicts with most, if not
all, currently unmerged changes.  There's over 20 branches pending in Bundle
Buggy alone, let alone changes that are still too immature to have been formally
proposed for merging yet.

It seems counter-productive to me to induce conflicts in an effort to avoid
conflicts that we don't have!

> If the code has been allowed to become inconsistent with whitespace,
> it seems the only long-term solution is to declare an
> automaticaly-checkable policy, convert the code base, and reject any
> future commit that doesn't conform.

You're presupposing that a solution is required, i.e. that the current state is
a problem.  I'm not convinced that this is the case.  The current high rate of
changes is evidence that it isn't problem.

> Would Benjamin's patch be better if a whitespace policy (such as
> "conform with PEP 8 whitespace suggestions", or even "ensure
> whitespace is as produced by reindent.py") were implemented, before a
> one-time fixup to the code base?

We already have a HACKING.txt file that says that in general people should
conform to PEP 8.  But note that PEP 8 doesn't ban trailing whitespace (it
merely says to avoid it in string literals), for instance.

-Andrew.