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 <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
