On 27/10/2011 06:44, Manuel M T Chakravarty wrote:
As a compromise, how about
(1) whitespace changes in separate Git commits, BUT
(2) only in bundled (i.e., in a simultaneously pushed commit set) with commits
that do perform functional changes?
Then, they are not just spurious changes in modules that actually didn't
change, but still easier to separate from functional changes when reviewing
commits.
Right, what I don't like is whitespace and formatting changes just for
the sake of it. If you're working in an area then it makes sense to
clean up formatting, whitespace, warnings etc. at the same time, but in
separate commits.
Cheers,
Simon
Manuel
Manuel M T Chakravarty:
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
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
