Hi Peter,
On Tue, 6 Sep 2016 16:47:56 +0200, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 04:34:13PM +0200, Jean Delvare wrote:
> > > [diff "default"]
> > > xfuncname = "^[[:alpha:]$_].*[^:]$"
> >
> > OK, I see. As mentioned somewhere else, it fails for labels which have
> > comments.
Hi Peter,
On Tue, 6 Sep 2016 16:47:56 +0200, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 04:34:13PM +0200, Jean Delvare wrote:
> > > [diff "default"]
> > > xfuncname = "^[[:alpha:]$_].*[^:]$"
> >
> > OK, I see. As mentioned somewhere else, it fails for labels which have
> > comments.
On Tue, 2016-09-06 at 16:47 +0200, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 04:34:13PM +0200, Jean Delvare wrote:
> > > [diff "default"]
> > > xfuncname = "^[[:alpha:]$_].*[^:]$"
> > OK, I see. As mentioned somewhere else, it fails for labels which have
> > comments.
> Heh, There's
On Tue, 2016-09-06 at 16:47 +0200, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 04:34:13PM +0200, Jean Delvare wrote:
> > > [diff "default"]
> > > xfuncname = "^[[:alpha:]$_].*[^:]$"
> > OK, I see. As mentioned somewhere else, it fails for labels which have
> > comments.
> Heh, There's
On Tue, Sep 06, 2016 at 04:34:13PM +0200, Jean Delvare wrote:
> > [diff "default"]
> > xfuncname = "^[[:alpha:]$_].*[^:]$"
>
> OK, I see. As mentioned somewhere else, it fails for labels which have
> comments.
Heh, There's labels that have comments?
> My worry is that you recommending
On Tue, Sep 06, 2016 at 04:34:13PM +0200, Jean Delvare wrote:
> > [diff "default"]
> > xfuncname = "^[[:alpha:]$_].*[^:]$"
>
> OK, I see. As mentioned somewhere else, it fails for labels which have
> comments.
Heh, There's labels that have comments?
> My worry is that you recommending
Hi Peter,
On Mon, 5 Sep 2016 13:58:38 +0200, Peter Zijlstra wrote:
> On Mon, Sep 05, 2016 at 01:54:45PM +0200, Jean Delvare wrote:
> > On Mon, 5 Sep 2016 13:37:04 +0200, Peter Zijlstra wrote:
> > > I have it in my local .gitconfig, and recommend it to people who send me
> > > patches.
> >
> >
Hi Peter,
On Mon, 5 Sep 2016 13:58:38 +0200, Peter Zijlstra wrote:
> On Mon, Sep 05, 2016 at 01:54:45PM +0200, Jean Delvare wrote:
> > On Mon, 5 Sep 2016 13:37:04 +0200, Peter Zijlstra wrote:
> > > I have it in my local .gitconfig, and recommend it to people who send me
> > > patches.
> >
> >
On Mon, Sep 05, 2016 at 01:54:45PM +0200, Jean Delvare wrote:
> On Mon, 5 Sep 2016 13:37:04 +0200, Peter Zijlstra wrote:
> > On Mon, Sep 05, 2016 at 01:07:37PM +0200, Jean Delvare wrote:
> > > Now I see in http://patchwork.ozlabs.org/patch/664966/ that Peter
> > > Zijlstra reportedly changed the
On Mon, Sep 05, 2016 at 01:54:45PM +0200, Jean Delvare wrote:
> On Mon, 5 Sep 2016 13:37:04 +0200, Peter Zijlstra wrote:
> > On Mon, Sep 05, 2016 at 01:07:37PM +0200, Jean Delvare wrote:
> > > Now I see in http://patchwork.ozlabs.org/patch/664966/ that Peter
> > > Zijlstra reportedly changed the
On Mon, 5 Sep 2016 13:37:04 +0200, Peter Zijlstra wrote:
> On Mon, Sep 05, 2016 at 01:07:37PM +0200, Jean Delvare wrote:
> > Now I see in http://patchwork.ozlabs.org/patch/664966/ that Peter
> > Zijlstra reportedly changed the behavior of "diff -p" so that it
> > handles unindented C labels
On Mon, 5 Sep 2016 13:37:04 +0200, Peter Zijlstra wrote:
> On Mon, Sep 05, 2016 at 01:07:37PM +0200, Jean Delvare wrote:
> > Now I see in http://patchwork.ozlabs.org/patch/664966/ that Peter
> > Zijlstra reportedly changed the behavior of "diff -p" so that it
> > handles unindented C labels
On Mon, Sep 05, 2016 at 01:07:37PM +0200, Jean Delvare wrote:
> Now I see in http://patchwork.ozlabs.org/patch/664966/ that Peter
> Zijlstra reportedly changed the behavior of "diff -p" so that it
> handles unindented C labels nicely. If this actually happens, it could
> change my point of view.
On Mon, Sep 05, 2016 at 01:07:37PM +0200, Jean Delvare wrote:
> Now I see in http://patchwork.ozlabs.org/patch/664966/ that Peter
> Zijlstra reportedly changed the behavior of "diff -p" so that it
> handles unindented C labels nicely. If this actually happens, it could
> change my point of view.
Hi Daniel,
Preliminary note: the SNR of Markus Elfring is incredibly low. I advise
you just ignore him.
On Sun, 04 Sep 2016 11:56:58 +0200, Daniel Borkmann wrote:
> I don't want to drag this thread onwards for (way) too long, but clearly "it
> is
> advised to indent labels with a single space
Hi Daniel,
Preliminary note: the SNR of Markus Elfring is incredibly low. I advise
you just ignore him.
On Sun, 04 Sep 2016 11:56:58 +0200, Daniel Borkmann wrote:
> I don't want to drag this thread onwards for (way) too long, but clearly "it
> is
> advised to indent labels with a single space
On 09/04/2016 09:20 AM, SF Markus Elfring wrote:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=865a1caa4b6b886babdd9d67e7c3608be4567a51
[ + Jonathan for above commit in linux-next ]
You seem to lack understanding of the difference
On 09/04/2016 09:20 AM, SF Markus Elfring wrote:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=865a1caa4b6b886babdd9d67e7c3608be4567a51
[ + Jonathan for above commit in linux-next ]
You seem to lack understanding of the difference
> It's not because I find improvements "uncomfortable", but rather it's
> because your changes are not seen as improvements in the first place.
What is your software development opinion for the update step
"[1/4] sparc: bpf_jit: Use kmalloc_array() in bpf_jit_compile()"
from this small patch
> It's not because I find improvements "uncomfortable", but rather it's
> because your changes are not seen as improvements in the first place.
What is your software development opinion for the update step
"[1/4] sparc: bpf_jit: Use kmalloc_array() in bpf_jit_compile()"
from this small patch
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=865a1caa4b6b886babdd9d67e7c3608be4567a51
>
> You seem to lack understanding of the difference between absolute
> requirements and "advice".
>
> As Sparc maintainer I can choose to not take
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=865a1caa4b6b886babdd9d67e7c3608be4567a51
>
> You seem to lack understanding of the difference between absolute
> requirements and "advice".
>
> As Sparc maintainer I can choose to not take
From: SF Markus Elfring
Date: Sun, 4 Sep 2016 09:20:55 +0200
> I guess that I will stumble on more software improvement opportunities
> you find harder to become comfortable with.
Improvement is a matter of opinion. So your statement assumes that
your changes are
From: SF Markus Elfring
Date: Sun, 4 Sep 2016 09:20:55 +0200
> I guess that I will stumble on more software improvement opportunities
> you find harder to become comfortable with.
Improvement is a matter of opinion. So your statement assumes that
your changes are an improvement, and everyone
From: SF Markus Elfring
Date: Sun, 4 Sep 2016 08:50:20 +0200
>>> NAK, just noise.
>>
>> And frankly I hate that leading space.
>
> Would you like to comment the recent update of the document "CodingStyle" any
> more?
>
From: SF Markus Elfring
Date: Sun, 4 Sep 2016 08:50:20 +0200
>>> NAK, just noise.
>>
>> And frankly I hate that leading space.
>
> Would you like to comment the recent update of the document "CodingStyle" any
> more?
>
>> NAK, just noise.
>
> And frankly I hate that leading space.
Would you like to comment the recent update of the document "CodingStyle" any
more?
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=865a1caa4b6b886babdd9d67e7c3608be4567a51
>> NAK, just noise.
>
> And frankly I hate that leading space.
Would you like to comment the recent update of the document "CodingStyle" any
more?
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=865a1caa4b6b886babdd9d67e7c3608be4567a51
28 matches
Mail list logo