Re: [PATCH] Add short author date to Fixes tag

Re: [PATCH] Add short author date to Fixes tag

[Alejandro Colomar]

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

Hi Steven, Greg,

[I'll reply to several sub-threads at once.]


[Message-ID: <20250113095101.4e0fff91@gandalf.local.home>]
On Mon, Jan 13, 2025 at 09:51:01AM -0500, Steven Rostedt wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> > $ git help fixes
> > 'fixes' is aliased to 'show --format='Fixes: %h ("%s")' -s'
>
> Hmm, I've just been manually adding the Fixes tags ;-) That's because when
> I add a fixes tag, I also do a more in depth analysis to make sure the
> commit being tagged is really the cause of the problem. A lot of my fixes
> tags are due to very subtle bugs, and a lot of times its a combination of
> event that happened.

I also precede the generation of the fixes tag with an in-depth
analysis.  However, that doesn't conflict with using a git alias to
generate it, once I've reached a conclusion.  I use this alias to
generate them, and it's quite handy:
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING.d/git#n46>

>
> That said, maybe one day I'll use a script or alias in the future.


[Message-ID: <20250111120935.769ab9a3@gandalf.local.home>]
On Sat, Jan 11, 2025 at 6:08 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 10 Jan 2025 16:21:35 -0800
> Jacob Keller <jacob.e.keller@intel.com> wrote:
>
> > I personally find the date helpful as it can help place a commit without
> > needing to take the extra time to do a lookup.
>
> I've never found dates to be meaningful. I'm always more concerned about
> when a commit was added to mainline. Thus the version where the commit was
> added is very important for me.

Indeed.  I agree with this, and it's a quite important difference.
The commit dates are strictly increasing, which means you can use the
date to perform a search of a commit, if there's a collision in the
hash (and possibly in the subject).

I documented this in the man-pages project, where I require the commit
date to appear in Fixes tags.
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING.d/patches/trailer#n16>

> This is why I keep a bare clone of Linus's
> tree and commonly do:
>
>  $ git describe --contains fd3040b9394c
> v5.19-rc1~159^2~154^2
>  $ git describe --contains a76053707dbf
> v5.15-rc1~157^2~376^2~4
>
> I can easily see that a76053707dbf was added in 5.15 and fd3040b9394c was
> added in 5.19. The amount of work needed to add dates to Fixes tags would
> greatly exceed the amount of added work someone would need to do to do the
> above operations if they wanted to know the order of commits.


[Message-ID: <2025011032-gargle-showing-7500@gregkh>]
Greg wrote (Fri, 10 Jan 2025 13:32:22 +0100):
> Please no, you will break all of our tooling and scripts that parse
> these types of fields.  The git commit id and commit header is all we
> need to properly determine this type of information, no need to add a
> date in here at all.
> 
[...]
> 
> So I don't think you need to add a date here.  Dates also really do not
> mean much with commits, what matters is what release a commit is in, not
> when it was originally made.  We have commits that take years to show up
> in a release, so if you only look at a date, you will be mistaken many
> times as it's not showing what came before what many times (i.e. we
> apply commits out-of-date-order all the time.)

As I said above, I agree that the commit date is the right choice.
Author dates can be out-of-date-order by years.  Commit dates are
necessarily in order, though.


[Message-ID: <20250110080331.04645768@gandalf.local.home>]
Steven wrote (Fri, 10 Jan 2025 08:03:31 -0500):
> How can it lead to misjudgment? If you have two or more hashes matching, do
> you really think they'll have the same subjects?

The possibility isn't zero.  Statistically, it's quite low.  However,
it's non-zero.

$ git log --format=tformat:'%s' | sort | uniq -c | sort | tail
    248 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
    263 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
    275 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
    293 Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
    314 Merge branch 'akpm' (patches from Andrew)
    315 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
    318 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
    324 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
    369 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
    670 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
$ git log --format=tformat:'%s' | grep -v ^Merge | sort | uniq -c | sort | tail
grep: (standard input): binary file matches
     22 drm/amd/display: Clean up some inconsistent indenting
     25 Auto-update from upstream
     26 [ARM] Update mach-types
     26 pmdomain: Merge branch fixes into next
     30 s390: update defconfigs
     32 tools arch x86: Sync the msr-index.h copy with the kernel sources
     38 [SPARC64]: Update defconfig.
     52 mmc: Merge branch fixes into next
     59 drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()
     62 batman-adv: Start new development cycle

Subjects repeat every now and then, and the entropy in some subjects is
actually quite low.

If you include the commit date in a Fixes tag, then you preclude the
entire possibility of a commit reference clash, because you won't have
two patches committed in the same date with the same subject and same
hash (unless you *really* try)


[Message-ID: <2025011115-energize-edge-c9c7@gregkh>]
Greg wrote (Sat, 11 Jan 2025 06:48:53 +0100):
> And if it isn't long enough, tools like:
>	https://lore.kernel.org/r/20241226220555.3540872-1-sashal@kernel.org
> can help figure it out as well.

That uses hash+subject.  This may be not enough in some cases (see how
much subjects repeat, in the logs above).  And importantly, a fixes tag
may become ambiguous *after* it has been written, so you can't predict
much.

By having a commit date in the Fixes tag, you could even simplify the
script to just do a binary search in case of ambiguity.  Let's say I
want to find the following commit (arbitrarily taken from the first
Fixes tag I've found in my copy of linux.git):

	a2e459555c5f (2023-08-09; "shmem: stable directory offsets")

We could find it, with a trivial command line.  We only even need two
characters of the hash:

	$ git log --oneline --after='2023-08-08' --before='2023-08-10' \
	| grep ^a2;
	a2e459555c5f shmem: stable directory offsets

No need for a huge script to disambiguate.  This is even typo-resistant,
as one could eventually find something that is similar enough, if one
had such a field with a typo (in any of the three fields).  You'd be
able to search by the other two fields, and two fields should be
_usually_ enough for disambiguating, and the third one could corroborate
the typo.

So, what would you think of having the commit date in commit references
such as Fixes tags?


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] Add short author date to Fixes tag

[Alejandro Colomar]

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

D'oh!  I forgot to add the In-Reply-To tag.

I meant to reply to
<https://lore.kernel.org/all/52541f79-ba1c-49c9-a576-45c3472d1c79@intel.com/T/#mf183db5f382b4a39cf52a4a1d2ca8f96697c312e>


On 2026-02-25T01:56:08+0100, Alejandro Colomar wrote:
> Hi Steven, Greg,
> 
> [I'll reply to several sub-threads at once.]
> 
> 
> [Message-ID: <20250113095101.4e0fff91@gandalf.local.home>]
> On Mon, Jan 13, 2025 at 09:51:01AM -0500, Steven Rostedt wrote:
> > Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> 
> > > $ git help fixes
> > > 'fixes' is aliased to 'show --format='Fixes: %h ("%s")' -s'
> >
> > Hmm, I've just been manually adding the Fixes tags ;-) That's because when
> > I add a fixes tag, I also do a more in depth analysis to make sure the
> > commit being tagged is really the cause of the problem. A lot of my fixes
> > tags are due to very subtle bugs, and a lot of times its a combination of
> > event that happened.
> 
> I also precede the generation of the fixes tag with an in-depth
> analysis.  However, that doesn't conflict with using a git alias to
> generate it, once I've reached a conclusion.  I use this alias to
> generate them, and it's quite handy:
> <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING.d/git#n46>
> 
> >
> > That said, maybe one day I'll use a script or alias in the future.
> 
> 
> [Message-ID: <20250111120935.769ab9a3@gandalf.local.home>]
> On Sat, Jan 11, 2025 at 6:08 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Fri, 10 Jan 2025 16:21:35 -0800
> > Jacob Keller <jacob.e.keller@intel.com> wrote:
> >
> > > I personally find the date helpful as it can help place a commit without
> > > needing to take the extra time to do a lookup.
> >
> > I've never found dates to be meaningful. I'm always more concerned about
> > when a commit was added to mainline. Thus the version where the commit was
> > added is very important for me.
> 
> Indeed.  I agree with this, and it's a quite important difference.
> The commit dates are strictly increasing, which means you can use the
> date to perform a search of a commit, if there's a collision in the
> hash (and possibly in the subject).
> 
> I documented this in the man-pages project, where I require the commit
> date to appear in Fixes tags.
> <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING.d/patches/trailer#n16>
> 
> > This is why I keep a bare clone of Linus's
> > tree and commonly do:
> >
> >  $ git describe --contains fd3040b9394c
> > v5.19-rc1~159^2~154^2
> >  $ git describe --contains a76053707dbf
> > v5.15-rc1~157^2~376^2~4
> >
> > I can easily see that a76053707dbf was added in 5.15 and fd3040b9394c was
> > added in 5.19. The amount of work needed to add dates to Fixes tags would
> > greatly exceed the amount of added work someone would need to do to do the
> > above operations if they wanted to know the order of commits.
> 
> 
> [Message-ID: <2025011032-gargle-showing-7500@gregkh>]
> Greg wrote (Fri, 10 Jan 2025 13:32:22 +0100):
> > Please no, you will break all of our tooling and scripts that parse
> > these types of fields.  The git commit id and commit header is all we
> > need to properly determine this type of information, no need to add a
> > date in here at all.
> > 
> [...]
> > 
> > So I don't think you need to add a date here.  Dates also really do not
> > mean much with commits, what matters is what release a commit is in, not
> > when it was originally made.  We have commits that take years to show up
> > in a release, so if you only look at a date, you will be mistaken many
> > times as it's not showing what came before what many times (i.e. we
> > apply commits out-of-date-order all the time.)
> 
> As I said above, I agree that the commit date is the right choice.
> Author dates can be out-of-date-order by years.  Commit dates are
> necessarily in order, though.
> 
> 
> [Message-ID: <20250110080331.04645768@gandalf.local.home>]
> Steven wrote (Fri, 10 Jan 2025 08:03:31 -0500):
> > How can it lead to misjudgment? If you have two or more hashes matching, do
> > you really think they'll have the same subjects?
> 
> The possibility isn't zero.  Statistically, it's quite low.  However,
> it's non-zero.
> 
> $ git log --format=tformat:'%s' | sort | uniq -c | sort | tail
>     248 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>     263 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
>     275 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>     293 Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
>     314 Merge branch 'akpm' (patches from Andrew)
>     315 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
>     318 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
>     324 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>     369 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
>     670 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> $ git log --format=tformat:'%s' | grep -v ^Merge | sort | uniq -c | sort | tail
> grep: (standard input): binary file matches
>      22 drm/amd/display: Clean up some inconsistent indenting
>      25 Auto-update from upstream
>      26 [ARM] Update mach-types
>      26 pmdomain: Merge branch fixes into next
>      30 s390: update defconfigs
>      32 tools arch x86: Sync the msr-index.h copy with the kernel sources
>      38 [SPARC64]: Update defconfig.
>      52 mmc: Merge branch fixes into next
>      59 drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()
>      62 batman-adv: Start new development cycle
> 
> Subjects repeat every now and then, and the entropy in some subjects is
> actually quite low.
> 
> If you include the commit date in a Fixes tag, then you preclude the
> entire possibility of a commit reference clash, because you won't have
> two patches committed in the same date with the same subject and same
> hash (unless you *really* try)
> 
> 
> [Message-ID: <2025011115-energize-edge-c9c7@gregkh>]
> Greg wrote (Sat, 11 Jan 2025 06:48:53 +0100):
> > And if it isn't long enough, tools like:
> >	https://lore.kernel.org/r/20241226220555.3540872-1-sashal@kernel.org
> > can help figure it out as well.
> 
> That uses hash+subject.  This may be not enough in some cases (see how
> much subjects repeat, in the logs above).  And importantly, a fixes tag
> may become ambiguous *after* it has been written, so you can't predict
> much.
> 
> By having a commit date in the Fixes tag, you could even simplify the
> script to just do a binary search in case of ambiguity.  Let's say I
> want to find the following commit (arbitrarily taken from the first
> Fixes tag I've found in my copy of linux.git):
> 
> 	a2e459555c5f (2023-08-09; "shmem: stable directory offsets")
> 
> We could find it, with a trivial command line.  We only even need two
> characters of the hash:
> 
> 	$ git log --oneline --after='2023-08-08' --before='2023-08-10' \
> 	| grep ^a2;
> 	a2e459555c5f shmem: stable directory offsets
> 
> No need for a huge script to disambiguate.  This is even typo-resistant,
> as one could eventually find something that is similar enough, if one
> had such a field with a typo (in any of the three fields).  You'd be
> able to search by the other two fields, and two fields should be
> _usually_ enough for disambiguating, and the third one could corroborate
> the typo.
> 
> So, what would you think of having the commit date in commit references
> such as Fixes tags?
> 
> 
> Have a lovely night!
> Alex
> 
> -- 
> <https://www.alejandro-colomar.es>



-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] Add short author date to Fixes tag

[Greg Kroah-Hartman]

On Wed, Feb 25, 2026 at 01:56:02AM +0100, Alejandro Colomar wrote:
> [Message-ID: <2025011032-gargle-showing-7500@gregkh>]
> Greg wrote (Fri, 10 Jan 2025 13:32:22 +0100):
> > Please no, you will break all of our tooling and scripts that parse
> > these types of fields.  The git commit id and commit header is all we
> > need to properly determine this type of information, no need to add a
> > date in here at all.
> > 
> [...]
> > 
> > So I don't think you need to add a date here.  Dates also really do not
> > mean much with commits, what matters is what release a commit is in, not
> > when it was originally made.  We have commits that take years to show up
> > in a release, so if you only look at a date, you will be mistaken many
> > times as it's not showing what came before what many times (i.e. we
> > apply commits out-of-date-order all the time.)
> 
> As I said above, I agree that the commit date is the right choice.
> Author dates can be out-of-date-order by years.  Commit dates are
> necessarily in order, though.

Commit date also doesn't matter.  If I commit a fix to one of my
branches today, but Linus pulls it in in 2 years from now, what would
that date really show to anyone?

Again, all that matters is when a commit is in a release, and for that
you walk the tree/graph to determine it.  Please don't consider changing
the format of our commit identification logic as we have tools that
parse and handle what we have today, and all would be changed if we were
to change it.

Especially when it doesn't even provide any specific value that I can
see, if you want that info, just get it directly from git after looking
it up.

thanks,

greg k-h

Re: [PATCH] Add short author date to Fixes tag

[Alejandro Colomar]

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

Hi Greg,

On 2026-02-25T10:00:06-0800, Greg Kroah-Hartman wrote:
> On Wed, Feb 25, 2026 at 01:56:02AM +0100, Alejandro Colomar wrote:
> > [Message-ID: <2025011032-gargle-showing-7500@gregkh>]
> > Greg wrote (Fri, 10 Jan 2025 13:32:22 +0100):
> > > Please no, you will break all of our tooling and scripts that parse
> > > these types of fields.  The git commit id and commit header is all we
> > > need to properly determine this type of information, no need to add a
> > > date in here at all.
> > > 
> > [...]
> > > 
> > > So I don't think you need to add a date here.  Dates also really do not
> > > mean much with commits, what matters is what release a commit is in, not
> > > when it was originally made.  We have commits that take years to show up
> > > in a release, so if you only look at a date, you will be mistaken many
> > > times as it's not showing what came before what many times (i.e. we
> > > apply commits out-of-date-order all the time.)
> > 
> > As I said above, I agree that the commit date is the right choice.
> > Author dates can be out-of-date-order by years.  Commit dates are
> > necessarily in order, though.
> 
> Commit date also doesn't matter.  If I commit a fix to one of my
> branches today, but Linus pulls it in in 2 years from now, what would
> that date really show to anyone?

I think this is a bit confused.

If you commit a fix for a commit that is in Linus's tree, your Fixes tag
will refer to the mainline commit, and the Fixes tag will remain valid
if the fix is pulled by Linus in the future, because it will continue to
refer to the same commit with the same hash and date.

The case where it would matter is if you commit a fix for a commit that
is only in your stable branch.  However, since the stable branches are
not real branches, but actually a set of patches, I expect you would
just drop the faulty patch, right?

I expect any Fixes tag refers to commits in Linus's tree, right?
Otherwise, they are dangling references, except to those who know where
to find the commit.  If all Fixes tags refer to commits in Linus's tree,
then all Fixes tags are stable.

The commit date is tied to a commit and its hash, and the date will
remain valid as much as the hash itself.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] Add short author date to Fixes tag

[James Bottomley]

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

On Wed, 2026-02-25 at 19:20 +0100, Alejandro Colomar wrote:
> > Commit date also doesn't matter.  If I commit a fix to one of my
> > branches today, but Linus pulls it in in 2 years from now, what
> > would that date really show to anyone?
> 
> I think this is a bit confused.

Let me try another explanation: we only change tag formats for what
most people agree is a compelling reason (because of the script
breakage it causes among other things).  Your reasons so far aren't
compelling.

> If you commit a fix for a commit that is in Linus's tree, your Fixes
> tag will refer to the mainline commit, and the Fixes tag will remain
> valid if the fix is pulled by Linus in the future, because it will
> continue to refer to the same commit with the same hash and date.
> 
> The case where it would matter is if you commit a fix for a commit
> that is only in your stable branch.  However, since the stable
> branches are not real branches, but actually a set of patches, I
> expect you would just drop the faulty patch, right?

I think this is a bit confused.  The decision to rebase or revert is a
balancing act which depends how many people have seen (and possibly
rely on) the branch with the original commit in it.

> I expect any Fixes tag refers to commits in Linus's tree, right?
> Otherwise, they are dangling references, except to those who know
> where to find the commit.  If all Fixes tags refer to commits in
> Linus's tree, then all Fixes tags are stable.

I believe one of the prerequisites for changing current process should
be actually understanding how it works today.

> The commit date is tied to a commit and its hash, and the date will
> remain valid as much as the hash itself.

The argument isn't about validity, it's about utility.  Most of the
tasks we do don't care about the date and for the odd occasion we do
care we can follow the hash to get it.

Regards,

James



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 265 bytes --]

Re: [PATCH] Add short author date to Fixes tag

[Sasha Levin]

On Wed, Feb 25, 2026 at 01:56:02AM +0100, Alejandro Colomar wrote:
>Steven wrote (Fri, 10 Jan 2025 08:03:31 -0500):
>> How can it lead to misjudgment? If you have two or more hashes matching, do
>> you really think they'll have the same subjects?
>
>The possibility isn't zero.  Statistically, it's quite low.  However,
>it's non-zero.
>
>$ git log --format=tformat:'%s' | sort | uniq -c | sort | tail
>    248 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>    263 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
>    275 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>    293 Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
>    314 Merge branch 'akpm' (patches from Andrew)
>    315 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
>    318 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
>    324 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>    369 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
>    670 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>$ git log --format=tformat:'%s' | grep -v ^Merge | sort | uniq -c | sort | tail
>grep: (standard input): binary file matches
>     22 drm/amd/display: Clean up some inconsistent indenting
>     25 Auto-update from upstream
>     26 [ARM] Update mach-types
>     26 pmdomain: Merge branch fixes into next
>     30 s390: update defconfigs
>     32 tools arch x86: Sync the msr-index.h copy with the kernel sources
>     38 [SPARC64]: Update defconfig.
>     52 mmc: Merge branch fixes into next
>     59 drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()
>     62 batman-adv: Start new development cycle
>
>Subjects repeat every now and then, and the entropy in some subjects is
>actually quite low.
>
>If you include the commit date in a Fixes tag, then you preclude the
>entire possibility of a commit reference clash, because you won't have
>two patches committed in the same date with the same subject and same
>hash (unless you *really* try)

The probability of a collision where two commits share both the same
abbreviated SHA1 and the same subject line is so astronomically low that it's
not a realistic concern.

For context, Linus himself pushed back on merely extending the 12-character
SHA1 abbreviation to 13. A change that wouldn't even break existing scripts.
Yet the proposal here is to introduce an entirely new date parameter that's
incompatible with the current format, all to address a scenario that is
unlikely in practice.

-- 
Thanks,
Sasha

Re: [PATCH] Add short author date to Fixes tag

[Greg Kroah-Hartman]

On Wed, Feb 25, 2026 at 07:20:25PM +0100, Alejandro Colomar wrote:
> Hi Greg,
> 
> On 2026-02-25T10:00:06-0800, Greg Kroah-Hartman wrote:
> > On Wed, Feb 25, 2026 at 01:56:02AM +0100, Alejandro Colomar wrote:
> > > [Message-ID: <2025011032-gargle-showing-7500@gregkh>]
> > > Greg wrote (Fri, 10 Jan 2025 13:32:22 +0100):
> > > > Please no, you will break all of our tooling and scripts that parse
> > > > these types of fields.  The git commit id and commit header is all we
> > > > need to properly determine this type of information, no need to add a
> > > > date in here at all.
> > > > 
> > > [...]
> > > > 
> > > > So I don't think you need to add a date here.  Dates also really do not
> > > > mean much with commits, what matters is what release a commit is in, not
> > > > when it was originally made.  We have commits that take years to show up
> > > > in a release, so if you only look at a date, you will be mistaken many
> > > > times as it's not showing what came before what many times (i.e. we
> > > > apply commits out-of-date-order all the time.)
> > > 
> > > As I said above, I agree that the commit date is the right choice.
> > > Author dates can be out-of-date-order by years.  Commit dates are
> > > necessarily in order, though.
> > 
> > Commit date also doesn't matter.  If I commit a fix to one of my
> > branches today, but Linus pulls it in in 2 years from now, what would
> > that date really show to anyone?
> 
> I think this is a bit confused.
> 
> If you commit a fix for a commit that is in Linus's tree, your Fixes tag
> will refer to the mainline commit, and the Fixes tag will remain valid
> if the fix is pulled by Linus in the future, because it will continue to
> refer to the same commit with the same hash and date.

But we do not need the date!  It provides no additional information that
we can't just look up if we really need it.

The HASH ("text") format does 2 things, it provides an id we can use to
look up more, and the text is there to give humans a hint if they don't
want or need to look it up.  There is no need to include anything else,
let's keep it simple please.

thanks,

greg k-h

Re: [PATCH] Add short author date to Fixes tag

[Alejandro Colomar]

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

Hi Greg,

On 2026-02-25T13:23:24-0800, Greg Kroah-Hartman wrote:
> > > Commit date also doesn't matter.  If I commit a fix to one of my
> > > branches today, but Linus pulls it in in 2 years from now, what would
> > > that date really show to anyone?
> > 
> > I think this is a bit confused.
> > 
> > If you commit a fix for a commit that is in Linus's tree, your Fixes tag
> > will refer to the mainline commit, and the Fixes tag will remain valid
> > if the fix is pulled by Linus in the future, because it will continue to
> > refer to the same commit with the same hash and date.
> 
> But we do not need the date!  It provides no additional information that
> we can't just look up if we really need it.
> 
> The HASH ("text") format does 2 things, it provides an id we can use to
> look up more, and the text is there to give humans a hint if they don't
> want or need to look it up.

The date gives more information to humans to decide if the commit is
important to look up.  Sometimes, a subject can be ambiguous to the
human, even if it's not ambiguous to a machine.  The date can help give
some context to a human.  For example, one could relate a commit to a
series that was merged around that date.

The date uses few characters, so it's not too expensive in terms of
space.  You may even take some space back by dropping a few characters
from the hash.  Also, by having a fixed-width, it doesn't distract much,
as all subjects will still be aligned, so the eyes can jump it easily if
not interesting (just like the hash).

I appreciate seeing the date in my Fixes tags elsewhere, as it avoids
looking up some commits, which I would look up if I hadn't seen the
date.

Secondarily, it helps with the ID, in case it becomes ambiguous.  But
I started using it for the human part of it.

>  There is no need to include anything else,
> let's keep it simple please.

Okay; I won't insist.


Have a lovely night!
Alex

> 
> thanks,
> 
> greg k-h

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] Add short author date to Fixes tag

[Theodore Tso]

On Wed, Feb 25, 2026 at 10:45:48PM +0100, Alejandro Colomar wrote:
> The date gives more information to humans to decide if the commit is
> important to look up.  Sometimes, a subject can be ambiguous to the
> human, even if it's not ambiguous to a machine.  The date can help give
> some context to a human.  For example, one could relate a commit to a
> series that was merged around that date.

I'm really confused under what circumstances the date would ever be
*useful* to me.  In general, what I want to know is "is this fix
applicable to a branch I care about", which basically means I want to
know if a particular branch (a) has the commit id, or (b) has a commit
whose description contains a "commit upstream" line referencing the
commit.

The date is almost never interesting to me.  For upstream commits in
Linus's tree, the hint:

   Cc: stable@kernel.org # 6.8+

Is a bit more interesting to me, but so long as there's a fixes tag
with a commit ID, I can just do a "git tag --contains <commit-id>" to
get the same information.

					- Ted

Re: [PATCH] Add short author date to Fixes tag

[Mark Brown]

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

On Mon, Jan 13, 2025 at 09:51:01AM -0500, Steven Rostedt wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> > $ git help fixes
> > 'fixes' is aliased to 'show --format='Fixes: %h ("%s")' -s'

> Hmm, I've just been manually adding the Fixes tags ;-) That's because when
> I add a fixes tag, I also do a more in depth analysis to make sure the
> commit being tagged is really the cause of the problem. A lot of my fixes
> tags are due to very subtle bugs, and a lot of times its a combination of
> event that happened.

> That said, maybe one day I'll use a script or alias in the future.

I use an alias like that for manually adding fixes tags, to get
everything in the right format.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] Add short author date to Fixes tag

[Steven Rostedt]

On Sun, 12 Jan 2025 11:54:21 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> FTR, while I do not support adding dates to Fixes-tags, I would just
> need to make a small modification to my fixes alias:
> 
> $ git help fixes
> 'fixes' is aliased to 'show --format='Fixes: %h ("%s")' -s'

Hmm, I've just been manually adding the Fixes tags ;-) That's because when
I add a fixes tag, I also do a more in depth analysis to make sure the
commit being tagged is really the cause of the problem. A lot of my fixes
tags are due to very subtle bugs, and a lot of times its a combination of
event that happened.


That said, maybe one day I'll use a script or alias in the future.

-- Steve

Re: [PATCH] Add short author date to Fixes tag

[Geert Uytterhoeven]

Hi Steven,

On Sat, Jan 11, 2025 at 6:08 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 10 Jan 2025 16:21:35 -0800
> Jacob Keller <jacob.e.keller@intel.com> wrote:
>
> > I personally find the date helpful as it can help place a commit without
> > needing to take the extra time to do a lookup.
>
> I've never found dates to be meaningful. I'm always more concerned about
> when a commit was added to mainline. Thus the version where the commit was
> added is very important for me. This is why I keep a bare clone of Linus's
> tree and commonly do:
>
>  $ git describe --contains fd3040b9394c
> v5.19-rc1~159^2~154^2
>  $ git describe --contains a76053707dbf
> v5.15-rc1~157^2~376^2~4
>
> I can easily see that a76053707dbf was added in 5.15 and fd3040b9394c was
> added in 5.19. The amount of work needed to add dates to Fixes tags would
> greatly exceed the amount of added work someone would need to do to do the
> above operations if they wanted to know the order of commits.

FTR, while I do not support adding dates to Fixes-tags, I would just
need to make a small modification to my fixes alias:

$ git help fixes
'fixes' is aliased to 'show --format='Fixes: %h ("%s")' -s'

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] Add short author date to Fixes tag

[Steven Rostedt]

On Fri, 10 Jan 2025 16:21:35 -0800
Jacob Keller <jacob.e.keller@intel.com> wrote:

> I personally find the date helpful as it can help place a commit without
> needing to take the extra time to do a lookup.

I've never found dates to be meaningful. I'm always more concerned about
when a commit was added to mainline. Thus the version where the commit was
added is very important for me. This is why I keep a bare clone of Linus's
tree and commonly do:

 $ git describe --contains fd3040b9394c
v5.19-rc1~159^2~154^2
 $ git describe --contains a76053707dbf
v5.15-rc1~157^2~376^2~4

I can easily see that a76053707dbf was added in 5.15 and fd3040b9394c was
added in 5.19. The amount of work needed to add dates to Fixes tags would
greatly exceed the amount of added work someone would need to do to do the
above operations if they wanted to know the order of commits.

-- Steve

Re: [PATCH] Add short author date to Fixes tag

[Greg Kroah-Hartman]

On Fri, Jan 10, 2025 at 04:21:35PM -0800, Jacob Keller wrote:
> However, all of the existing tooling we have for the kernel does not
> support the date, and I think its not worth trying to change it at this
> point. It doesn't make sense to break all this tooling for information
> which is accessible in other forms. Indeed, as long as the hash is
> sufficiently long, the change of a collision is minimal.

And if it isn't long enough, tools like:
	https://lore.kernel.org/r/20241226220555.3540872-1-sashal@kernel.org
can help figure it out as well.

thanks,

greg k-h

Re: [PATCH] Add short author date to Fixes tag

[Jacob Keller]

On 1/10/2025 5:03 AM, Steven Rostedt wrote:
> On Fri, 10 Jan 2025 12:20:09 +0000
> Yeking@Red54.com wrote:
> 
>> The old Fixes tag style is at least 10 years old. It lacks date
>> information, which can lead to misjudgment. So I added short author date
>> to avoid this. This make it clear at a glance and reduce
>> misunderstandings.
> 
> How can it lead to misjudgment? If you have two or more hashes matching, do
> you really think they'll have the same subjects?
> 
> I do not plan on doing this. It's pointless.
> 
> -- Steve

While the addition of the date is a widely used variant within the git
community, this was rejected by the kernel community in the past as
well. I remember posting fixes tags with the date several years ago and
getting push back.

I tried to find reference to these discussions but I can't seem to
locate them anymore on the archives.

I personally find the date helpful as it can help place a commit without
needing to take the extra time to do a lookup.

However, all of the existing tooling we have for the kernel does not
support the date, and I think its not worth trying to change it at this
point. It doesn't make sense to break all this tooling for information
which is accessible in other forms. Indeed, as long as the hash is
sufficiently long, the change of a collision is minimal.

Re: [PATCH] Add short author date to Fixes tag

[Steven Rostedt]

On Fri, 10 Jan 2025 12:20:09 +0000
Yeking@Red54.com wrote:

> The old Fixes tag style is at least 10 years old. It lacks date
> information, which can lead to misjudgment. So I added short author date
> to avoid this. This make it clear at a glance and reduce
> misunderstandings.

How can it lead to misjudgment? If you have two or more hashes matching, do
you really think they'll have the same subjects?

I do not plan on doing this. It's pointless.

-- Steve

Re: [PATCH] Add short author date to Fixes tag

[Greg Kroah-Hartman]

On Fri, Jan 10, 2025 at 12:20:09PM +0000, Yeking@Red54.com wrote:
> From: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
> 
> The old Fixes tag style is at least 10 years old. It lacks date
> information, which can lead to misjudgment. So I added short author date
> to avoid this. This make it clear at a glance and reduce
> misunderstandings.
> 
> For example:
> 
> Old Fixes tag style:
> * Fixes: fd3040b9394c ("net: ethernet: Add driver for Sunplus SP7021")
> * Fixes: a76053707dbf ("dev_ioctl: split out ndo_eth_ioctl")
> This will make people mistakenly think that "a76053707dbf" broke
> "fd3040b9394c".[1]
> 
> New Fixes tag style:
> * Fixes: fd3040b9394c ("net: ethernet: Add driver for Sunplus SP7021", 2022-05-08)
> * Fixes: a76053707dbf ("dev_ioctl: split out ndo_eth_ioctl", 2021-07-27)
> This makes it clear that the newly introduced driver did not follow the
> existing changes.

Please no, you will break all of our tooling and scripts that parse
these types of fields.  The git commit id and commit header is all we
need to properly determine this type of information, no need to add a
date in here at all.

There's no issue with "making things clear" that I can tell, and no,
listing multiple fixes lines does NOT mean that a previous line broke
something at all.  It just means that a single commit happened to fix
multiple commits (which frankly is a rare thing, and one that our
scripts already have a hard enough time dealing with...)

So I don't think you need to add a date here.  Dates also really do not
mean much with commits, what matters is what release a commit is in, not
when it was originally made.  We have commits that take years to show up
in a release, so if you only look at a date, you will be mistaken many
times as it's not showing what came before what many times (i.e. we
apply commits out-of-date-order all the time.)

thanks,

greg k-h

[PATCH] Add short author date to Fixes tag

[Yeking]

From: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>

The old Fixes tag style is at least 10 years old. It lacks date
information, which can lead to misjudgment. So I added short author date
to avoid this. This make it clear at a glance and reduce
misunderstandings.

For example:

Old Fixes tag style:
* Fixes: fd3040b9394c ("net: ethernet: Add driver for Sunplus SP7021")
* Fixes: a76053707dbf ("dev_ioctl: split out ndo_eth_ioctl")
This will make people mistakenly think that "a76053707dbf" broke
"fd3040b9394c".[1]

New Fixes tag style:
* Fixes: fd3040b9394c ("net: ethernet: Add driver for Sunplus SP7021", 2022-05-08)
* Fixes: a76053707dbf ("dev_ioctl: split out ndo_eth_ioctl", 2021-07-27)
This makes it clear that the newly introduced driver did not follow the
existing changes.

[1] https://lore.kernel.org/all/20250109180212.71e4e53c@kernel.org/

docs: submitting-patches: The short author date of old example
"54a4f0239f2e" is 2010-05-05, which is not immediately obvious as
YYYY-MM-DD, so change example.

Fixes: 8401aa1f5997 ("Documentation/SubmittingPatches: describe the Fixes: tag", 2014-06-06)
Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
---
 Documentation/process/5.Posting.rst           |  2 +-
 Documentation/process/maintainer-tip.rst      |  4 +--
 .../process/researcher-guidelines.rst         |  2 +-
 Documentation/process/submitting-patches.rst  |  8 ++---
 scripts/checkpatch.pl                         | 30 +++++++++++--------
 5 files changed, 25 insertions(+), 21 deletions(-)

diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
index b3eff03ea249..38c9c94e7448 100644
--- a/Documentation/process/5.Posting.rst
+++ b/Documentation/process/5.Posting.rst
@@ -199,7 +199,7 @@ document; what follows here is a brief summary.
 One tag is used to refer to earlier commits which introduced problems fixed by
 the patch::
 
-	Fixes: 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID")
+	Fixes: 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID", 2024-12-31)
 
 Another tag is used for linking web pages with additional backgrounds or
 details, for example an earlier discussion which leads to the patch or a
diff --git a/Documentation/process/maintainer-tip.rst b/Documentation/process/maintainer-tip.rst
index e374b67b3277..fb97a6853e42 100644
--- a/Documentation/process/maintainer-tip.rst
+++ b/Documentation/process/maintainer-tip.rst
@@ -270,7 +270,7 @@ Ordering of commit tags
 To have a uniform view of the commit tags, the tip maintainers use the
 following tag ordering scheme:
 
- - Fixes: 12char-SHA1 ("sub/sys: Original subject line")
+ - Fixes: 12char-SHA1 ("sub/sys: Original subject line", YYYY-MM-DD)
 
    A Fixes tag should be added even for changes which do not need to be
    backported to stable kernels, i.e. when addressing a recently introduced
@@ -295,7 +295,7 @@ following tag ordering scheme:
      The recent replacement of foo with bar left an unused instance of
      variable foo around. Remove it.
 
-     Fixes: abcdef012345678 ("x86/xxx: Replace foo with bar")
+     Fixes: abcdef012345678 ("x86/xxx: Replace foo with bar", 2024-12-31)
      Signed-off-by: J.Dev <j.dev@mail>
 
    The latter puts the information about the patch into the focus and
diff --git a/Documentation/process/researcher-guidelines.rst b/Documentation/process/researcher-guidelines.rst
index beb484c5965d..472ca0a4684d 100644
--- a/Documentation/process/researcher-guidelines.rst
+++ b/Documentation/process/researcher-guidelines.rst
@@ -149,7 +149,7 @@ For example::
   [1] https://url/to/leakmagic/details
 
   Reported-by: Researcher <researcher@email>
-  Fixes: aaaabbbbccccdddd ("Introduce support for FooBar")
+  Fixes: aaaabbbbccccdddd ("Introduce support for FooBar", 2024-12-31)
   Signed-off-by: Author <author@email>
   Reviewed-by: Reviewer <reviewer@email>
 
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 1518bd57adab..4df1e722130b 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -148,7 +148,7 @@ the SHA-1 ID, and the one line summary.  Do not split the tag across multiple
 lines, tags are exempt from the "wrap at 75 columns" rule in order to simplify
 parsing scripts.  For example::
 
-	Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
+	Fixes: 6a451e2c5c03 ("ALSA: hda/tas2781: Ignore SUBSYS_ID not found for tas2563 projects", 2024-12-30)
 
 The following ``git config`` settings can be used to add a pretty format for
 outputting the above style in the ``git log`` or ``git show`` commands::
@@ -156,12 +156,12 @@ outputting the above style in the ``git log`` or ``git show`` commands::
 	[core]
 		abbrev = 12
 	[pretty]
-		fixes = Fixes: %h (\"%s\")
+		fixes = Fixes: %h (\"%s\", %as)
 
 An example call::
 
-	$ git log -1 --pretty=fixes 54a4f0239f2e
-	Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
+	$ git log -1 --pretty=fixes 6a451e2c5c03
+	Fixes: 6a451e2c5c03 ("ALSA: hda/tas2781: Ignore SUBSYS_ID not found for tas2563 projects", 2024-12-30)
 
 .. _split_changes:
 
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 9eed3683ad76..580d5620ec7d 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1228,15 +1228,15 @@ sub git_is_single_file {
 }
 
 sub git_commit_info {
-	my ($commit, $id, $desc) = @_;
+	my ($commit, $id, $desc, $date) = @_;
 
-	return ($id, $desc) if ((which("git") eq "") || !(-e "$gitroot"));
+	return ($id, $desc, $date) if ((which("git") eq "") || !(-e "$gitroot"));
 
-	my $output = `${git_command} log --no-color --format='%H %s' -1 $commit 2>&1`;
+	my $output = `${git_command} log --no-color --format='%H %s %as' -1 $commit 2>&1`;
 	$output =~ s/^\s*//gm;
 	my @lines = split("\n", $output);
 
-	return ($id, $desc) if ($#lines < 0);
+	return ($id, $desc, $date) if ($#lines < 0);
 
 	if ($lines[0] =~ /^error: short SHA1 $commit is ambiguous/) {
 # Maybe one day convert this block of bash into something that returns
@@ -1253,10 +1253,11 @@ sub git_commit_info {
 		$id = undef;
 	} else {
 		$id = substr($lines[0], 0, 12);
-		$desc = substr($lines[0], 41);
+		$desc = substr($lines[0], 41, -11);
+		$date = substr($lines[0], -10);
 	}
 
-	return ($id, $desc);
+	return ($id, $desc, $date);
 }
 
 $chk_signoff = 0 if ($file);
@@ -3214,16 +3215,19 @@ sub process {
 			my $orig_commit = $2;
 			my $title;
 			my $title_has_quotes = 0;
+			my $date;
 			$fixes_tag = 1;
 			if (defined $3) {
+				$date = substr($3, -11, 10);
 				# Always strip leading/trailing parens then double quotes if existing
-				$title = substr($3, 1, -1);
+				$title = substr($3, 1, -13);
 				if ($title =~ /^".*"$/) {
 					$title = substr($title, 1, -1);
 					$title_has_quotes = 1;
 				}
 			} else {
-				$title = "commit title"
+				$title = "commit title";
+				$date = "YYYY-MM-DD";
 			}
 
 
@@ -3234,15 +3238,15 @@ sub process {
 			my $id_case = not ($orig_commit !~ /[A-F]/);
 
 			my $id = "0123456789ab";
-			my ($cid, $ctitle) = git_commit_info($orig_commit, $id,
-							     $title);
+			my ($cid, $ctitle, $cdate) = git_commit_info($orig_commit, $id,
+							     $title, $date);
 
-			if ($ctitle ne $title || $tag_case || $tag_space ||
+			if ($ctitle ne $title || $cdate ne $date || $tag_case || $tag_space ||
 			    $id_length || $id_case || !$title_has_quotes) {
 				if (WARN("BAD_FIXES_TAG",
-				     "Please use correct Fixes: style 'Fixes: <12 chars of sha1> (\"<title line>\")' - ie: 'Fixes: $cid (\"$ctitle\")'\n" . $herecurr) &&
+				     "Please use correct Fixes: style 'Fixes: <12 chars of sha1> (\"<title line>\", YYYY-MM-DD)' - ie: 'Fixes: $cid (\"$ctitle\", $cdate)'\n" . $herecurr) &&
 				    $fix) {
-					$fixed[$fixlinenr] = "Fixes: $cid (\"$ctitle\")";
+					$fixed[$fixlinenr] = "Fixes: $cid (\"$ctitle\", $cdate)";
 				}
 			}
 		}
-- 
2.43.0