Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935109AbcJGPiL (ORCPT ); Fri, 7 Oct 2016 11:38:11 -0400 Received: from twin.jikos.cz ([89.185.236.188]:34625 "EHLO twin.jikos.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936348AbcJGPha (ORCPT ); Fri, 7 Oct 2016 11:37:30 -0400 Date: Fri, 7 Oct 2016 17:35:24 +0200 (CEST) From: Jiri Kosina X-X-Sender: jikos@twin.jikos.cz To: SF Markus Elfring cc: "Austin S. Hemmelgarn" , Dan Carpenter , Richard Weinberger , "linux-raid@vger.kernel.org" , Christoph Hellwig , Guoqing Jiang , Jens Axboe , Mike Christie , Neil Brown , Shaohua Li , Tomasz Majchrzak , LKML , "kernel-janitors@vger.kernel.org" , Julia Lawall Subject: Re: md/raid1: Improve another size determination in setup_conf() In-Reply-To: Message-ID: References: <566ABCD9.1060404@users.sourceforge.net> <786843ef-4b6f-eb04-7326-2f6f5b408826@users.sourceforge.net> <9831fce9-d689-89e4-dec8-50cadcd13fdd@users.sourceforge.net> <20161007075345.GB6039@mwanda> <77d68bcd-1ae4-4808-fc0b-6183ae5fb6c4@users.sourceforge.net> <522db506-1e1c-0563-7595-da6dc701d706@users.sourceforge.net> <6e2c26bc-d765-6225-af72-157832ab8785@gmail.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 841 Lines: 26 On Fri, 7 Oct 2016, SF Markus Elfring wrote: > > but patches that just fix coding style are a bad thing > > When you find such a change opportunity so "bad", are there any > circumstances left over where you would dare to touch the corresponding > source code line. If you actually rewrite the code or fix some real bug there. > > because they break things like `git blame` > > I follow your concern to some degree. > > But can this argument evolve against a lot of changes generally? If I have to reiterate git blame multiple times just because of whitespace or codingstyle changes, it's a pure waste of my time. If I have to reiterate git blame multiple times to skip actual real changes, I have no other option than to live with that (because there was an actual functional reason for the change). -- Jiri Kosina SUSE Labs