Disallow pushing of new trailing whitespace

[Edward Z. Yang]

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
>