On Tue, Sep 02, 2003 at 11:12:46AM +0100, Colin Watson wrote:
> On Tue, Sep 02, 2003 at 11:43:19AM +0200, Anders Arnholm wrote:
> > On Tue, Sep 02, 2003 at 09:37:27AM +0100, Colin Watson wrote:
> > > Nowadays, on average I tend to use expandtab for new code, but
> > > converting tabs to spaces is still an operation that needs to be handled
> > > carefully with respect to revision control, so I don't apply it across
> > > the board.
> >
> > Almost all decent revision control programs tend to let you ignore
> > whitespace when doing diffs of a program.
>
> Other people working on the project still need to use that option, and
> it still makes annotate less convenient. Unnecessary cosmetic changes
> are always a pain, and if done at all they should always happen in
> separate commits to functional changes. (Wearing my code reviewer hat, I
> will jump up and down on your head if you mix cosmetic changes with
> functional changes. :))
Yes, it's good idea to keep it separate check ins. But that doesn't
changed the main thing i they are needed, e.g. the code is in bad
indention according to coding standard or something else like this. Make
the change, run the test suit, checking the changes (with comment
"update to follow coding standard." or something like that) and then
proceed with the other functional standards. Coding standard, tab/spaces
and some on is usually something you like to do before you start a
complex work. So that the the complex work gets a little easier. If
you like to compare versions operated by a syntax changes that the
ignore whitespace comes in handy.
/ Balp
--
o_ Anders Arnholm, HiQ - Consultant
o/ /\ anders@arnholm.nu Phone : +46-703-160969
/|_, \\ http://anders.arnholm.nu/ http://www.hiq.se
/
`
Attachment:
pgpxsLN_RpEdO.pgp
Description: PGP signature