Reformatting code

[simo]

On Sun, 2011-07-24 at 22:38 +0200, Volker Lendecke wrote:
> On Sun, Jul 24, 2011 at 04:08:17PM +0200, Jelmer Vernooij wrote:
> > >>On Fri, Jul 22, 2011 at 10:04:06AM +0200, Stefan (metze) Metzmacher wrote:
> > >>>http://lists.samba.org/archive/samba-technical/2011-June/078234.html
> > >>Yes, I know about that one. Has there been a resolution? I
> > >>think even back then I replied with some doubtful mail. Has
> > >>there been a definitive decision that this change is to be
> > >>done?
> > >No, but most of us thought it is a good idea to switch to
> > >just one style of using bool values.
> > Being consistent in the way we notate bools is definitely a good thing.
> > 
> > That said, there is a difference between fixing up old-style bools in 
> > code you are changing anyway, and actively reformatting code without 
> > making any other changes.
> > 
> > The latter makes it harder to track down its origin later, and adds 
> > noise to our revision history: it makes things like "git annotate" or 
> > "git log" harder to use. It's not worth the slight cosmetic improvement IMO.
> 
> That's exactly my point. If I change code lines anyway for
> other reasons, then I also change False->false. But just for
> the purpose of that change I leave it. But the two of us
> seem alone with this opinion, everybody else sees it
> differently.

git blame can be given a commit-id to get the previous history, so if a
"reformat" commit gets in your way you can always see what happened
earlier than that.

If cluttering git blame is the only reason I am also in the camp that
doesn't care as git can easily cope with that.

Also if these commits are properly labeled with the word "reformat" in
the title they are not really annoying to me, they too can be easily
skipped or simply ignored.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>