Disallow pushing of new trailing whitespace

[Edward Z. Yang]

Yes, I suppose this is a philosophical difference of whether or not
the compiler should enforce coding style. :)

Edward

Excerpts from Simon Marlow's message of Sat Aug 24 13:21:30 -0700 2013:
> 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
> >>