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? Again, all that matters is when a commit is in a release, and for that you walk the tree/graph to determine it. Please don't consider changing the format of our commit identification logic as we have tools that parse and handle what we have today, and all would be changed if we were to change it. Especially when it doesn't even provide any specific value that I can see, if you want that info, just get it directly from git after looking it up. thanks, greg k-h
