[MERGE] whitespace normalization

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ben Finney wrote:
> Aaron Bentley <aaron at aaronbentley.com> writes:
> 
>> Ben Finney wrote:
>>> The trouble is, I don't see what's preventing regressions from
>>> making their way in.
>> I don't think we need to be that rigid about whitespace.
> 
> I'm having trouble seeing how you reconcile that assertion with:
> 
>>> That is, if Bazaar developer Albert has their editor configured to
>>> fix whitespace automatically on files so he doesn't need to rely
>>> on error-prone manual whitespace editing, what prevents spurious
>>> conflicts with existing changes on lines that didn't already
>>> conform?
>> Albert's change will not be merged because of its spurious changes.
> 
> These two seem to contradict.

I think that contradiction is superficial.

Being "rigid" in the first case means never permitting a whitespace
regression.

Being "rigid" in the second case means not allowing spurious changes,
including whitespace-only changes, to be merged.  I would probably also
reject a patch changing UK spelling to US spelling.  Or one that
introduced parentheses around every return value.

> By definition, in this scenario, Albert's change conforms with the
> style guide; the existing lines do not. You're saying that Albert's
> change will be rejected, because of differences in whitespace.

I am saying the change will be rejected because it is a spurious change,
not specifically because it is a whitespace change.

> Isn't
> rejecting Albert's change over whitespace issues being overly rigid
> about whitespace?

No.  We like our developers.  We want to minimize the conflicts they
get.  So even if it was being "rigid about whitespace", I don't think
it's being *overly* rigid.

> Why reject a change to whitespace that conforms with the stated coding
> style guide, unless one *is* being rigid about whitespace?

Because one is rigid about spurious changes, not about whitespace changes.

Changes can cause conflicts.  Spurious changes can cause spurious conflicts.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIibv50F+nu1YWqI0RAmVuAJ9kZChsDVGqXlm27cxA/TI0E/6ipgCggOet
z2+TmnpmLQBbj8dteZ4fjUU=
=6pCk
-----END PGP SIGNATURE-----