Re: [Tracker] Whitespace clean up

[Martyn Russell <martyn lanedo com>]

On 08/12/09 22:16, Juan A. Suarez Romero wrote:
> On Tue, 2009-12-08 at 09:50 +0000, Martyn Russell wrote:
> > First we need to decide on tabs vs spaces and where. I think last time
> > this was discussed on IRC, people agreed to have spaces for function
> > alignments and tabs for indentation. Do people still agree with this?
>
> Is there any reason or advantage to use use tabs for indentation? Why
> not using spaces for everything?

Because some people use tab indentation of 4, some use 8, some use 2 I 
suppose. Using tabs means the editor lays it out how you like to see it.

> AFAIK, glib and gtk+ uses spaces for everything.

I think they use a mix actually.

> > I would like to try to make sure this is the case in the code and at the
> > same time remove any trailing white space. Choosing the right time for
> > this is important too because we have some branches which are likely to
> > have merge conflicts.
> >
> > Currently active non-merged branches:
> >
> >     mmc
> >     miner-web
> >     msword
> >     nautilus-extension
> >     nmo
> >     quad
> >     subqueries
> >
> > When makes sense to make these changes?
>
> As Philip said, I'd change nothing that is already commited just to get
> rid of tabs. Doing it the commit log history would be perverted. Rather,
> I think that the new rule should be applied for new commits.

I think we all agree here. With the git blame -w command as mentioned 
previously, we shouldn't worry about making whitespace changes for 
history reasons. Unless there is some other case I have completely 
overlooked here.

> I'm wondering if some hook can be added in git so in the pre-commit that
> hook can check if the new code follows the rule. IIRC, gstreamer have
> some hook to check some issues before performing a commit.

Ha, ironic that I didn't read your email before now but said the same 
thing in my reply to Philip. Yes, we should do this.

--
Regards,
Martyn