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