Formatting of stable commit messages

Formatting of stable commit messages

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

Dear Greg,


Looking at the change-log of the stable series, there are two lines 
between the commit messages summary [1] and the first line of the commit 
message body.

> commit 4c8e0270dc7afb10d4e06be4adfd177db5cb3cb8
> Author: Tang Junhui <tang.junhui@zte.com.cn>
> Date:   Wed Feb 7 11:41:46 2018 -0800
> 
>     bcache: fix for data collapse after re-attaching an attached device
>     
>     
>     [ Upstream commit 73ac105be390c1de42a2f21643c9778a5e002930 ]

I assume you scripts generate that. Could they be changed to just add 
one blank line?


Kind regards,

Paul


[1] https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.37


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]

Re: Formatting of stable commit messages

[Willy Tarreau]

Hello,

On Fri, Apr 27, 2018 at 11:34:58AM +0200, Paul Menzel wrote:
> Dear Greg,
> 
> 
> Looking at the change-log of the stable series, there are two lines between
> the commit messages summary [1] and the first line of the commit message
> body.
> 
> > commit 4c8e0270dc7afb10d4e06be4adfd177db5cb3cb8
> > Author: Tang Junhui <tang.junhui@zte.com.cn>
> > Date:   Wed Feb 7 11:41:46 2018 -0800
> > 
> >     bcache: fix for data collapse after re-attaching an attached device
> >     [ Upstream commit 73ac105be390c1de42a2f21643c9778a5e002930 ]
> 
> I assume you scripts generate that. Could they be changed to just add one
> blank line?

Just FWIW the ones appearing in the changelog seem to only affect Sasha's
autosel commits, which have a From line in the body. It might be that the
automatic removal of this From leaves only the previous and next empty
lines, resulting in what you observe.

Just my two cents,
Willy

Re: Formatting of stable commit messages

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 11:34:58AM +0200, Paul Menzel wrote:
> Dear Greg,
> 
> 
> Looking at the change-log of the stable series, there are two lines between
> the commit messages summary [1] and the first line of the commit message
> body.
> 
> > commit 4c8e0270dc7afb10d4e06be4adfd177db5cb3cb8
> > Author: Tang Junhui <tang.junhui@zte.com.cn>
> > Date:   Wed Feb 7 11:41:46 2018 -0800
> > 
> >     bcache: fix for data collapse after re-attaching an attached device
> >     [ Upstream commit 73ac105be390c1de42a2f21643c9778a5e002930 ]
> 
> I assume you scripts generate that. Could they be changed to just add one
> blank line?

It's my script that messes with that, sometimes, and not others.  I
haven't really taken the time to figure it out, it's here:
	https://github.com/gregkh/gregkh-linux/blob/master/stable/dave_split.pl
if you want to figure it out :)

Is this really causing a problem with anything?  It's just an "extra"
blank line, nothing is being attributed incorrectly.

thanks,

greg k-h

Re: Formatting of stable commit messages

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 12:03:44PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Apr 27, 2018 at 11:34:58AM +0200, Paul Menzel wrote:
> > Dear Greg,
> > 
> > 
> > Looking at the change-log of the stable series, there are two lines between
> > the commit messages summary [1] and the first line of the commit message
> > body.
> > 
> > > commit 4c8e0270dc7afb10d4e06be4adfd177db5cb3cb8
> > > Author: Tang Junhui <tang.junhui@zte.com.cn>
> > > Date:   Wed Feb 7 11:41:46 2018 -0800
> > > 
> > >     bcache: fix for data collapse after re-attaching an attached device
> > >     [ Upstream commit 73ac105be390c1de42a2f21643c9778a5e002930 ]
> > 
> > I assume you scripts generate that. Could they be changed to just add one
> > blank line?
> 
> It's my script that messes with that, sometimes, and not others.  I
> haven't really taken the time to figure it out, it's here:
> 	https://github.com/gregkh/gregkh-linux/blob/master/stable/dave_split.pl
> if you want to figure it out :)
> 
> Is this really causing a problem with anything?  It's just an "extra"
> blank line, nothing is being attributed incorrectly.

Ok, now that I see this, I can't "unsee" it, so I fixed the issue in my
script.  Shouldn't happen again.

thanks,

greg k-h