linux-kernel - Re: [PATCH][Trivial] Delete trailing whitespace from sound/soc/codecs/wm8994.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 9 Apr 2012 20:07:27 +0000
From:	Michael Witten <mfwitten@...il.com>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Jesper Juhl <jj@...osbits.net>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH][Trivial] Delete trailing whitespace from sound/soc/codecs/wm8994.c

On Mon, Apr 9, 2012 at 00:29, Jiri Kosina <jkosina@...e.cz> wrote:
> On Mon, 9 Apr 2012, Michael Witten wrote:
>
>> >> While reading through sound/soc/codecs/wm8994.c I noticed a fair
>> >> amount of trailing whitespace. This patch gets rid of it.
>> >>
>> >> Signed-off-by: Jesper Juhl <jj@...osbits.net>
>> >
>> > Jesper,
>> >
>> > is it really worth it? The code should have been fixed before merging,
>> > yes, but once it's there, such fixups tend to only make people angry
>> > (because they have to do unnecessary extra steps during git blame).
>>
>> If I may interject, I assume you mean that nobody wants to see the
>> fact that somebody simply changed whitespace. However, the text of
>> `git help blame' suggests that the `-w' flag obviates the issue:
>>
>>   Ignore whitespace when comparing the parent's
>>   version and the child’s to find where the lines
>>   came from.
>>
>> Of course, I've never used it, so I may be mistaken in my
>> interpretation.
>
> That indeed does what it should do, but as it's not git default, then
> quitting git blame and reruning it with '-w' seems to be equally annoying
> to quitting git blame and reruning it with 'particular_commit~1"

It seems to me that something must be terribly wrong with our tools
and workflows whenever an improvement (for which the main work has
already been done, no less) is turned down.

Perhaps that `-w' option should become the default.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/