Disallow pushing of new trailing whitespace

[Simon Marlow]

There's some justification for -fwarn-tabs: tabs can lead to confusing 
failures when people use the wrong tab setting in their editor.  On the 
other hand, I don't think there's any good reason for having the 
compiler warn about trailing whitespace.

Cheers,
	Simon

On 22/08/13 17:18, Edward Z. Yang wrote:
> GHC already has -fwarn-tabs; we could have -fwarn-trailing-whitespace
> and turn it on by default, so that validate errors on it but you also
> notice it when you're doing a build (if you're paying attention to
> warnings).
>
> Edward
>
> Excerpts from Simon Marlow's message of Thu Aug 22 05:04:50 -0700 2013:
>> On 22/08/13 12:32, Austin Seipp wrote:
>>> This seems acceptable IMO. The general working conventions already are
>>> to separate whitespace and/or tab changes from a commit containing
>>> actual content. If you ./validate cleanly, but the server rejects the
>>> push for whitespace, adding an extra commit on top to clean up the
>>> affected files seems very sensible (it's simple to 'untabify' and
>>> eliminate trailing white space in most editors these days, so I imagine
>>> this isn't really going to cost you a lot of time.)
>>
>> You still have to validate the new commit, so it costs you at least 20
>> mins, which is a lot.
>>
>>> I also add bonus
>>> points for the fact the server will reject it unless you clean up *all*
>>> affected files you touched, so things can't slip by. This is how the tab
>>> check works now, and it does deal with a 'range' of commits where later
>>> commits eliminate tabs introduced in earlier ones.
>>>
>>> We'd also have to introduce the concept of git into ./validate for this
>>> to work (and add the ability to specify a commit range for stuff like
>>> this,) but a basic implementation may not be difficult, looking at the
>>> pre-receive script.
>>
>> Checking everything in 'git rev-list origin..' is probably good enough.
>>
>> Cheers,
>>      Simon
>>
>>> Alternatively, these could be pre-commit hooks in the developer
>>> repository, but I believe you have to opt into that. Maybe worth putting
>>> on the wiki, though.
>>>
>>>
>>>
>>> On Thu, Aug 22, 2013 at 2:33 AM, Simon Marlow <marlowsd at gmail.com
>>> <mailto:marlowsd at gmail.com>> wrote:
>>>
>>>      On 20/08/13 12:21, Geoffrey Mainland wrote:
>>>
>>>          Would be nice to have. How about a third hook that disallows commits
>>>          that include whitespace-only changes unless *all* changes are
>>>          whitespace-only? ;)
>>>
>>>
>>>      The problem with these kind of commit-time checks is that you only
>>>      find out the problem *after* you've validated your nicely polished
>>>      commits. If we're going to add more checks on commits they should be
>>>      done by validate (yes I know that's not at all trivial, but it's not
>>>      impossible either).
>>>
>>>      Cheers,
>>>               Simon
>>>
>>>
>>>
>>>
>>>          Geoff
>>>
>>>          On 08/20/2013 10:59 AM, Jan Stolarek wrote:
>>>
>>>              Right now we have a git hook that prevents pushing a file
>>>              containing tabs, unless that file had them already (in other
>>>              words: no new files with tabs in our repos). I propose to
>>>              add similar hook for trailing whitespaces. Herbert says he
>>>              can implement that. What do others think? Would you find
>>>              that useful or problematic?
>>>
>>>              Janek
>>>
>>>
>>>          _________________________________________________
>>>          ghc-devs mailing list
>>>          ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>>          http://www.haskell.org/__mailman/listinfo/ghc-devs
>>>          <http://www.haskell.org/mailman/listinfo/ghc-devs>
>>>
>>>
>>>
>>>      _________________________________________________
>>>      ghc-devs mailing list
>>>      ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>>      http://www.haskell.org/__mailman/listinfo/ghc-devs
>>>      <http://www.haskell.org/mailman/listinfo/ghc-devs>
>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Austin - PGP: 4096R/0x91384671
>>