linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Chen Gang <chengang@emindsoft.com.cn>
To: Jiri Kosina <jikos@kernel.org>
Cc: Mel Gorman <mgorman@techsingularity.net>,
	akpm@linux-foundation.org, vbabka@suse.cz, rientjes@google.com,
	linux-kernel@vger.kernel.org, mhocko@suse.cz, hannes@cmpxchg.org,
	vdavydov@virtuozzo.com, dan.j.williams@intel.com,
	linux-mm@kvack.org, Chen Gang <gang.chen.5i5j@gmail.com>
Subject: Re: [PATCH trivial] include/linux/gfp.h: Improve the coding styles
Date: Fri, 26 Feb 2016 22:57:36 +0800	[thread overview]
Message-ID: <56D067E0.2000201@emindsoft.com.cn> (raw)
In-Reply-To: <alpine.LNX.2.00.1602252334400.22700@cbobk.fhfr.pm>

On 2/26/16 06:39, Jiri Kosina wrote:
> On Fri, 26 Feb 2016, Chen Gang wrote:
> 
>> git is a tool mainly for analyzing code, but not mainly for normal
>> reading main code.
>>
>> So for me, the coding styles need not consider about git.
> 
> You are mistaken here. It's very helpful when debugging;

For me, 'debugging' is related with debugger (e.g. kdb or kgdb), and
'tracing' is related with dumping log, and code analyzing is related
with "git diff" and "git blame".

And yes, for me, "git diff" and "git blame" is really very helpful for
code analyzing.

>                                                         usually you want 
> to find the commit that introduced particular change, and read its 
> changelog (at least). Having to cross rather pointless changes just adds 
> time (need to restart git-blame with commit~1 as a base) for no really 
> good reason.
> 

That is the reason why I am not quite care about body files, I often use
"git log -p filename", the cleanup code patch has negative effect with
code analyzing (although for me, it should still need to be cleanup).

But in our case, it is for the shared header file:

 - They are often the common base file, the main contents will not be
   changed quite often, and their contents are usually simple enough (
   e.g. gfp.h in our case), they are not often for "code analyzing".

 - But they are quite often read in normal reading ways by programmers
   (e.g. open with normal editors). For normal reading, programmers
   usually care about the contents, not the changes.

 - So for me, the common shared header files need always take care about
   coding styles, and need not consider about code analyzing.

And if we reject this kind of patch (in our case), I guess, that almost
mean: "for the common shared header files, their bad coding styles will
be remain for ever".


Thanks.
-- 
Chen Gang (e??a??)

Managing Natural Environments is the Duty of Human Beings.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-02-26 14:54 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-24 22:26 chengang
2016-02-25  1:01 ` SeongJae Park
2016-02-25 14:12   ` Chen Gang
2016-02-25  8:57 ` Michal Hocko
2016-02-25 14:23   ` Chen Gang
2016-02-25 14:47     ` Michal Hocko
2016-02-25 22:17       ` Chen Gang
2016-02-25  9:27 ` Mel Gorman
2016-02-25 14:38   ` Chen Gang
2016-02-25 15:12     ` Jiri Kosina
2016-02-25 22:19       ` Chen Gang
2016-02-25 16:07     ` Mel Gorman
2016-02-25 22:29       ` Chen Gang
2016-02-25 22:39         ` Jiri Kosina
2016-02-26 14:57           ` Chen Gang [this message]
2016-02-25 23:12         ` SeongJae Park
2016-02-26 15:06           ` Chen Gang
2016-02-26  2:32         ` Jianyu Zhan
2016-02-26 15:26           ` Chen Gang
2016-02-27  2:45             ` Theodore Ts'o
2016-02-27 14:32               ` Chen Gang
2016-02-27 16:53                 ` Theodore Ts'o
2016-02-28  0:21                   ` Chen Gang
2016-02-28 13:27                     ` Mel Gorman
2016-02-28 15:28                       ` Chen Gang
2016-02-27 23:14                 ` Jiri Kosina
2016-02-28  0:47                   ` Chen Gang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56D067E0.2000201@emindsoft.com.cn \
    --to=chengang@emindsoft.com.cn \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=gang.chen.5i5j@gmail.com \
    --cc=hannes@cmpxchg.org \
    --cc=jikos@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.cz \
    --cc=rientjes@google.com \
    --cc=vbabka@suse.cz \
    --cc=vdavydov@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox