2022-11-28 21:31:03

by Stephen Rothwell

[permalink] [raw]
Subject: linux-next: Fixes tag needs some work in the block tree

Hi all,

In commit

4b49197f9fbd ("block: mq-deadline: Rename deadline_is_seq_writes()")

Fixes tag

Fixes: 015d02f4853 ("block: mq-deadline: Do not break sequential write streams to zoned HDDs")

has these problem(s):

- SHA1 should be at least 12 digits long
This can be fixed for the future by setting core.abbrev to 12 (or
more) or (for git v2.11 or later) just making sure it is not set
(or set to "auto").

--
Cheers,
Stephen Rothwell


Attachments:
(No filename) (499.00 B)
OpenPGP digital signature

2022-11-29 00:08:46

by Damien Le Moal

[permalink] [raw]
Subject: Re: linux-next: Fixes tag needs some work in the block tree

On 11/29/22 06:27, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 4b49197f9fbd ("block: mq-deadline: Rename deadline_is_seq_writes()")
>
> Fixes tag
>
> Fixes: 015d02f4853 ("block: mq-deadline: Do not break sequential write streams to zoned HDDs")
>
> has these problem(s):
>
> - SHA1 should be at least 12 digits long
> This can be fixed for the future by setting core.abbrev to 12 (or
> more) or (for git v2.11 or later) just making sure it is not set
> (or set to "auto").

Oops. Sorry about that. It seems I cannot count up to 12 anymore :)
It should be:

Fixes: 015d02f48537 ("block: mq-deadline: Do not break sequential write
streams to zoned HDDs")

Jens, can you fix this ?

--
Damien Le Moal
Western Digital Research

2022-11-29 03:34:37

by Damien Le Moal

[permalink] [raw]
Subject: Re: linux-next: Fixes tag needs some work in the block tree

On 11/29/22 11:30, Jens Axboe wrote:
> On 11/28/22 4:39?PM, Damien Le Moal wrote:
>> On 11/29/22 06:27, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> In commit
>>>
>>> 4b49197f9fbd ("block: mq-deadline: Rename deadline_is_seq_writes()")
>>>
>>> Fixes tag
>>>
>>> Fixes: 015d02f4853 ("block: mq-deadline: Do not break sequential write streams to zoned HDDs")
>>>
>>> has these problem(s):
>>>
>>> - SHA1 should be at least 12 digits long
>>> This can be fixed for the future by setting core.abbrev to 12 (or
>>> more) or (for git v2.11 or later) just making sure it is not set
>>> (or set to "auto").
>>
>> Oops. Sorry about that. It seems I cannot count up to 12 anymore :)
>> It should be:
>>
>> Fixes: 015d02f48537 ("block: mq-deadline: Do not break sequential write
>> streams to zoned HDDs")
>>
>> Jens, can you fix this ?
>
> Sure, it's not that important though as it's just missing one digit. For
> the record, this is what I have in my .gitconfig :
>
> [alias]
> fixes = log -1 --format=fixes
>
> [pretty]
> fixes = Fixes: %h (\"%s\")
>
> [core]
> abbrev = 12
>
> and then you just do 'git fixes <sha>' and it spits out the line for the
> commit without needing to count anything and eliminates this error.

Thanks for the info. Will try this !

--
Damien Le Moal
Western Digital Research

2022-11-29 03:35:22

by Jens Axboe

[permalink] [raw]
Subject: Re: linux-next: Fixes tag needs some work in the block tree

On 11/28/22 4:39?PM, Damien Le Moal wrote:
> On 11/29/22 06:27, Stephen Rothwell wrote:
>> Hi all,
>>
>> In commit
>>
>> 4b49197f9fbd ("block: mq-deadline: Rename deadline_is_seq_writes()")
>>
>> Fixes tag
>>
>> Fixes: 015d02f4853 ("block: mq-deadline: Do not break sequential write streams to zoned HDDs")
>>
>> has these problem(s):
>>
>> - SHA1 should be at least 12 digits long
>> This can be fixed for the future by setting core.abbrev to 12 (or
>> more) or (for git v2.11 or later) just making sure it is not set
>> (or set to "auto").
>
> Oops. Sorry about that. It seems I cannot count up to 12 anymore :)
> It should be:
>
> Fixes: 015d02f48537 ("block: mq-deadline: Do not break sequential write
> streams to zoned HDDs")
>
> Jens, can you fix this ?

Sure, it's not that important though as it's just missing one digit. For
the record, this is what I have in my .gitconfig :

[alias]
fixes = log -1 --format=fixes

[pretty]
fixes = Fixes: %h (\"%s\")

[core]
abbrev = 12

and then you just do 'git fixes <sha>' and it spits out the line for the
commit without needing to count anything and eliminates this error.


--
Jens Axboe