On Wed, Feb 25, 2026 at 10:45:48PM +0100, Alejandro Colomar wrote:
> 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.
No it does not, that is what the subject determines.
> Sometimes, a subject can be ambiguous to the human, even if it's not
> ambiguous to a machine.
Then work with the developers to not provide such subject lines. Don't
rely on a date for anything, that doesn't help.
> 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.
Again, dates of commit time do not reflect the date of the release it
shows up in.
> 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.
That's great, but again, for the kernel we don't need or want this. If
you do want this, great, you can add it yourself as Sasha just showed.
> 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
