Normally, for a large project, this loss of history is much worse than
the damage caused by inconsistent indentation (and sometime guidelines
actually discourage fixing indentation in order to keep from polluting
the change history).
I use this program, in conjunction with Vim:
http://www.kylheku.com/cgit/c-snippets/tree/autotab.c
This is geared toward languages which resemble C. (Patches, suggestions,
critisms welcome).
With the help of this utility, I instantly conform to the indentation style of
the source file that I load into Vim's buffer.
Without this program, I would go crazy working with multiple code bases that
have different conventions, and with inconsistent conventions within the same
project.
Worse, I might accidentally introduce edits which use a different style; for
instance spaces when the existing code uses hard tabs or vice versa.
Conforming to the exiting style is more important than enforcing one.
If a project contains numerous files that are inconsistently formatted
internally, it may be a good idea to fix them. It should be discussed with the
team; you don't just go in and reindent everything. Since the changes may
cause merge conflicts, cleanup work should be coordinated with the release
management process. For instance, if you still have an old branch that is
active (bugs are being fixed for customers and then integrated into the
mainline), then maybe hold off with the whitespace changes, so that changes can
back- and forward-port easily.
It's also a poor idea to mix whitespace changes with an actual code change,
needless to add.