Add short author date to Fixes tag

Quoted 2 lines · Geert Uytterhoeven

$ 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.

Quoted 2 lines · On Fri, 10 Jan 2025 16:21:35 -0800 Jacob Keller <[email protected]>…

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.

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.)

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

And if it isn't long enough, tools like:

	https://lore.kernel.org/r/[email protected]

can help figure it out as well.

Hi Steven, Greg,

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

[Message-ID: <[email protected]>]

Quoted 10 lines · Steven Rostedt

Quoted 2 lines · Geert Uytterhoeven

$ 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>

Quoted 2 lines

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

[Message-ID: <[email protected]>]

Quoted 9 lines · Steven Rostedt

Quoted 2 lines · On Fri, 10 Jan 2025 16:21:35 -0800 Jacob Keller <[email protected]>…

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>

Quoted 8 lines

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

Quoted 4 lines

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):

Quoted 5 lines

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.

[...]

Quoted 7 lines

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: <[email protected]>] Steven wrote (Fri, 10 Jan 2025 08:03:31 -0500):

Quoted 2 lines

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):

Quoted 3 lines

And if it isn't long enough, tools like:

	https://lore.kernel.org/r/[email protected]

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

Signature · 1 line

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

[Message-ID: <2025011032-gargle-showing-7500@gregkh>] Greg wrote (Fri, 10 Jan 2025 13:32:22 +0100):

Quoted 5 lines

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.

[...]

Quoted 7 lines

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.

Quoted 16 lines · Alejandro Colomar

[Message-ID: <2025011032-gargle-showing-7500@gregkh>] Greg wrote (Fri, 10 Jan 2025 13:32:22 +0100):

Quoted 5 lines

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.

[...]

Quoted 7 lines

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.)

Quoted 3 lines

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?

Quoted 3 lines

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.

Hi Greg,

Quoted 17 lines · Greg Kroah-Hartman

Quoted 16 lines · Alejandro Colomar

[Message-ID: <2025011032-gargle-showing-7500@gregkh>] Greg wrote (Fri, 10 Jan 2025 13:32:22 +0100):

Quoted 5 lines

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.

[...]

Quoted 7 lines

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.)

Quoted 7 lines

Quoted 3 lines

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.

Quoted 10 lines

Quoted 3 lines

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

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 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.

Hi Greg,

Quoted 14 lines · Greg Kroah-Hartman

Quoted 10 lines

Quoted 3 lines

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.

Quoted 3 lines

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.

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.

Quoted 2 lines

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

Our ids are not ambiguous. Our "problem" is people putting git ids in the logs that are not valid git ids. Just happened again today as we are "human". Putting the date in there would not help with that very real problem we have today at all.

thanks,

greg k-h

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?

Steven wrote (Fri, 10 Jan 2025 08:03:31 -0500):

Quoted 2 lines

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)

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?

Quoted 2 lines · On Wed, 25 Feb 2026 01:56:02 +0100 Alejandro Colomar <[email protected]> wrote:

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

Most of those repeats are merges. And people tend to use the same subject when they merge commits. The only time a Fixes is for a merge is if there was a merge conflict and it was done poorly.

Quoted 8 lines

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):

Quoted 8 lines

	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

Why not just git show a2e459555c5f? You're just worried because of conflicts? That happens so seldom doing a bit more work to find the task is less work than every developer adding a useless date in the tag.

Even if there are conflicts, git show shows you all the commits that conflict:

(random example)

$ git show cbced
error: short object ID cbced is ambiguous
hint: The candidates are:
hint:   cbced93894d1 commit 2026-02-02 - drm/amd/display: Set CRTC source for DAC using registers
hint:   cbced0de1ae7 tree
hint:   cbced35df940 tree
hint:   cbced38b00f6 tree
hint:   cbced53122ce tree
hint:   cbced7856638 tree
hint:   cbced88f5140 tree
hint:   cbceda69074d tree
hint:   cbcedadcc0f9 tree
hint:   cbced8ff29d4 blob
hint:   cbcedd7a684b blob

The above only has one with a subject.

Quoted 10 lines

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?

NAK. I really see no purpose for it, and just adds added noise to the Fixes tag. Seriously, your example above:

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

Looks horrible compared to:

a2e459555c5f ("shmem: stable directory offsets")

You are the first one to complain about needing a date here. Who else finds this useful in the kernel community? It really feels like it's a solution looking for a problem.

Sorry,

-- Steve