[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: Whitespace cleanups
From:       Jerome Leclanche <adys.wh () gmail ! com>
Date:       2009-11-28 12:33:48
Message-ID: 41eceb530911280433i3c533902k96dce709a21eb1c2 () mail ! gmail ! com
[Download RAW message or body]

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 changes...


J. Leclanche / Adys



On Fri, Nov 27, 2009 at 7:27 AM, Ken Thomases <ken@codeweavers.com> wrote:
> 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. They just make it a bit
>> harder to use.
>>
>> Let's say your 'git-blame dlls/mshtml/tests/dom.c' leads you to commit
>> 1e4412d7 which, by looking at it, you decide is a false positive. Then
>> you do:
>>
>>  $ git cat-file -p 1e4412d7
>>  tree ea3b2e117b383ade8afc7cc9bf534c48faf891c7
>>  parent 44f520a5b6f2bd6ec6da8793177711e57bda9c72
>>  author Francois Gouget <fgouget@free.fr> 1258539107 +0100
>>  committer Alexandre Julliard <julliard@winehq.org> 1258553736 +0100
>>
>>  mshtml/tests: Add a trailing '\n' to ok() calls.
>>
>> Then you run git-blame again:
>>
>>  git blame 44f520a5 dlls/mshtml/tests/dom.c
>>
>> And continue the analysis until you find the right culprit.
>
> Um, it's just easier to add a caret ('^') to the commit ID.
>
> git blame 1e4412d7^ dlls/mshtml/tests/dom.c
>
> I'm well aware of this technique, but if it doesn't make git-blame useless,
> it makes it a hell of a lot less useful, especially if whitespace-only
> changes become non-rare.  I wasn't aware of and haven't tried Kai's
> suggestion of using the -w switch.
>
> -Ken
>
>
>
>



[prev in list] [next in list] [prev in thread] [next in thread]