On Wed, Feb 25, 2026 at 07:20:25PM +0100, Alejandro Colomar wrote:
> Hi Greg,
> 
> On 2026-02-25T10:00:06-0800, Greg Kroah-Hartman wrote:
> > On Wed, Feb 25, 2026 at 01:56:02AM +0100, Alejandro Colomar wrote:
> > > [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.
> > 
> > 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

Reply via email to