I was just working on shell32/shlview.c: ShellView_OnNotify.
There is so much mixing between tabs, spaces, different indent levels,
trailing whitespace and what not that the code is properly unreadable.
git-blame is one thing, but when it goes as far as almost preventing a
developer to make change
On Nov 26, 2009, at 10:15 AM, Francois Gouget wrote:
On Wed, 25 Nov 2009, Ken Thomases wrote:
[...]
One important reason to avoid whitespace-only changes is it makes
git-blame essentially useless for finding the real source of
functional changes.
Such changes don't make git-blame useless. The
On Wed, 25 Nov 2009, Ken Thomases wrote:
[...]
> One important reason to avoid whitespace-only changes is it makes
> git-blame essentially useless for finding the real source of
> functional changes.
Such changes don't make git-blame useless. They just make it a bit
harder to use.
Let's say yo
On Wednesday 25 November 2009 19:02:08 Ken Thomases wrote:
> On Nov 25, 2009, at 11:13 AM, Nate Gallaher wrote:
> > Ken Thomases wrote:
> >> One important reason to avoid whitespace-only changes is it makes
> >> git-blame essentially useless for finding the real source of functional
> >> changes.
>
On Nov 25, 2009, at 11:13 AM, Nate Gallaher wrote:
> Ken Thomases wrote:
>> One important reason to avoid whitespace-only changes is it makes git-blame
>> essentially useless for finding the real source of functional changes.
>>
>
> But is that really important? git-bisect would put you on the
Ken Thomases wrote:
One important reason to avoid whitespace-only changes is it makes git-blame
essentially useless for finding the real source of functional changes.
But is that really important? git-bisect would put you on the other
side of any whitespace changes, and a prudent bug-hunter
On Nov 25, 2009, at 9:13 AM, Nate Gallaher wrote:
> I understand the "preserve existing format" rule, particularly in cases of
> braces, inter-paren spacing, variable
> names, function names, and alignment, but I don't see the benefit of keeping
> 80-cols insanity around.
One important reason
Nikolay Sivov wrote:
or should I just fix the
one function I'm planning on touching? Or should I grit my teeth
and ignore the style issues
entirely?
Yes, in most cases. If you plan to rework the whole file with
functional patches feel free to touch
formatting a bit. The common rule is to pre
, I found whitespace errors in the code I'm working on and had to fix them
as well.
James McKenzie
-Original Message-
>From: Nikolay Sivov
>Sent: Nov 25, 2009 7:55 AM
>To: Nate Gallaher
>Cc: wine-devel@winehq.org
>Subject: Re: Whitespace cleanups
>
>Nate Gallahe
Nate Gallaher wrote:
I'm looking at working on a new area of wine (for me) and the file I'm
going to be working
with is rife with whitespace issues. Literal tabs are sprinkled
around and the 80-col limit
has been broken badly and often in easily fixable ways. I'm wondering
what the acceptable
I'm looking at working on a new area of wine (for me) and the file I'm
going to be working
with is rife with whitespace issues. Literal tabs are sprinkled around
and the 80-col limit
has been broken badly and often in easily fixable ways. I'm wondering
what the acceptable
approach is to these
11 matches
Mail list logo
