From: Alejandro Colomar <alx@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Mark Brown <broonie@kernel.org>, Sasha Levin <sashal@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Jacob Keller <jacob.e.keller@intel.com>,
Yeking@red54.com, kuba@kernel.org,
Jonathan Corbet <corbet@lwn.net>, Theodore Ts'o <tytso@mit.edu>,
Andy Whitcroft <apw@canonical.com>,
Joe Perches <joe@perches.com>,
Dwaipayan Ray <dwaipayanray1@gmail.com>,
Lukas Bulwahn <lukas.bulwahn@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
workflows@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
tech-board-discuss@lists.linux.dev, Andrew Lunn <andrew@lunn.ch>
Subject: Re: [PATCH] Add short author date to Fixes tag
Date: Wed, 25 Feb 2026 22:45:48 +0100 [thread overview]
Message-ID: <aZ9p2RMrJL1mQ10w@devuan> (raw)
In-Reply-To: <2026022539-commotion-huskiness-8736@gregkh>
[-- 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 --]
next prev parent reply other threads:[~2026-02-25 21:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 0:56 Alejandro Colomar
2026-02-25 0:57 ` Alejandro Colomar
2026-02-25 18:00 ` Greg Kroah-Hartman
2026-02-25 18:20 ` Alejandro Colomar
2026-02-25 19:47 ` James Bottomley
2026-02-25 21:23 ` Greg Kroah-Hartman
2026-02-25 21:45 ` Alejandro Colomar [this message]
2026-02-25 22:35 ` Theodore Tso
2026-02-25 23:27 ` Sasha Levin
2026-02-25 23:46 ` Greg Kroah-Hartman
2026-02-26 0:20 ` Alejandro Colomar
2026-02-25 20:08 ` Sasha Levin
2026-02-26 0:08 ` Steven Rostedt
[not found] <tencent_6CF6E720909156A227D23AE8CFE4F9BA5D05@qq.com>
2025-01-10 12:20 ` Yeking
2025-01-10 12:32 ` Greg Kroah-Hartman
2025-01-10 13:03 ` Steven Rostedt
2025-01-11 0:21 ` Jacob Keller
2025-01-11 5:48 ` Greg Kroah-Hartman
2025-01-11 17:09 ` Steven Rostedt
2025-01-12 10:54 ` Geert Uytterhoeven
2025-01-13 14:51 ` Steven Rostedt
2025-01-13 15:08 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aZ9p2RMrJL1mQ10w@devuan \
--to=alx@kernel.org \
--cc=Yeking@red54.com \
--cc=akpm@linux-foundation.org \
--cc=andrew@lunn.ch \
--cc=apw@canonical.com \
--cc=broonie@kernel.org \
--cc=corbet@lwn.net \
--cc=dwaipayanray1@gmail.com \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=jacob.e.keller@intel.com \
--cc=joe@perches.com \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=rostedt@goodmis.org \
--cc=sashal@kernel.org \
--cc=tech-board-discuss@lists.linux.dev \
--cc=tytso@mit.edu \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox