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 <marlo...@gmail.com > > <mailto:marlo...@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@haskell.org <mailto:ghc-devs@haskell.org> > > http://www.haskell.org/__mailman/listinfo/ghc-devs > > <http://www.haskell.org/mailman/listinfo/ghc-devs> > > > > > > > > _________________________________________________ > > ghc-devs mailing list > > ghc-devs@haskell.org <mailto:ghc-devs@haskell.org> > > http://www.haskell.org/__mailman/listinfo/ghc-devs > > <http://www.haskell.org/mailman/listinfo/ghc-devs> > > > > > > > > > > -- > > Regards, > > Austin - PGP: 4096R/0x91384671 > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
