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

[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

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

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

[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

[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

[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

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

[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 --]