Simon Marlow: > (incedentally, I'm not keen on patches that *just* make whitespace changes. > It causes unnecessary conflicts in my branches.)
http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Git says > Separate changes that affect functionality from those that just affect code > layout, indendation, whitespace, filenames etc. This means that when looking > at patches later, we don't have to wade through loads of non-functional > changes to get to the important parts of the patch. Manuel > > On 26/10/2011 08:31, Simon Peyton-Jones wrote: >> I don't have an opinion. Simon M is the king. >> >> S >> >> | -----Original Message----- >> | From: omega.th...@gmail.com [mailto:omega.th...@gmail.com] On Behalf Of Max >> | Bolingbroke >> | Sent: 26 October 2011 08:21 >> | To: cvs-ghc@haskell.org; Simon Peyton-Jones; Simon Marlow; Ian Lynagh >> | Subject: Re: [commit: ghc] master: Tabs -> spaces (9ada6542b) >> | >> | Ian/Simon/Simon, >> | >> | Do you have an opinion on this? My proposal below has support from >> | David, Manuel and Daniel Fischer, but I don't want to go installing >> | new git hooks without your go-ahead! >> | >> | Max >> | >> | On 25 October 2011 11:52, Max Bolingbroke<batterseapo...@hotmail.com> >> wrote: >> |> If we are going to make whitespace changes, we should probably have a >> |> check to ensure that tabs don't get added back in by later commits. >> |> I've created a pre-receive hook that verifies the following property: >> |> >> |> Taken *as a whole*, the series of commits you are trying to push.. >> |> ..for all file *modified* (i.e. I'm ignoring renames) by the commits.. >> |> ..that do not contain tabs *before* the push.. >> |> ..your commits do not add a *new* line containing a tab >> |> >> |> Your push is rejected with a list of all violations if this property >> |> is violated. At this point you can either write a new patch that fixes >> |> the validation problems, or just rebase to edit the commit introducing >> |> the problem. >> |> >> |> I've also written a pre-commit hook that GHC developers could copy >> |> into their own git repos to ensure that such bad commits never get >> |> created in the first place. >> |> >> |> Is this something we want to check? Should we use this pre-receive >> |> hook on darcs.haskell.org? >> |> >> |> Max >> |> >> |> On 25 October 2011 10:17, Manuel Chakravarty<c...@cse.unsw.edu.au> >> wrote: >> |>> Repository : ssh://darcs.haskell.org//srv/darcs/ghc >> |>> >> |>> On branch : master >> |>> >> |>> >> | >> http://hackage.haskell.org/trac/ghc/changeset/9ada6542bad350664b6991b33dc675daac99979 >> | 3 >> |>> >> |>>>--------------------------------------------------------------- >> |>> >> |>> commit 9ada6542bad350664b6991b33dc675daac999793 >> |>> Author: Manuel M T Chakravarty<c...@cse.unsw.edu.au> >> |>> Date: Wed Oct 19 16:09:37 2011 +1100 >> |>> >> |>> Tabs -> spaces >> |>> >> |>> compiler/iface/TcIface.lhs | 856 >> ++++++++++++++++++++++---------------------- >> |>> 1 files changed, 429 insertions(+), 427 deletions(-) >> |>> >> |>> >> |>> Diff suppressed because of size. To see it, use: >> |>> >> |>> git show 9ada6542bad350664b6991b33dc675daac999793 >> |>> >> |>> _______________________________________________ >> |>> Cvs-ghc mailing list >> |>> Cvs-ghc@haskell.org >> |>> http://www.haskell.org/mailman/listinfo/cvs-ghc >> |>> >> |> >> >> > > > _______________________________________________ > Cvs-ghc mailing list > Cvs-ghc@haskell.org > http://www.haskell.org/mailman/listinfo/cvs-ghc _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
