Re: [PATCH] Add short author date to Fixes tag

On 2/25/2026 4:08 PM, Steven Rostedt wrote:
> On Wed, 25 Feb 2026 01:56:02 +0100
> Alejandro Colomar <[email protected]> wrote:
> 
>> That uses hash+subject.  This may be not enough in some cases (see how
>> much subjects repeat, in the logs above).  And importantly, a fixes tag
> 
> Most of those repeats are merges. And people tend to use the same
> subject when they merge commits. The only time a Fixes is for a merge
> is if there was a merge conflict and it was done poorly.
> 
>> may become ambiguous *after* it has been written, so you can't predict
>> much.
>>
>> By having a commit date in the Fixes tag, you could even simplify the
>> script to just do a binary search in case of ambiguity.  Let's say I
>> want to find the following commit (arbitrarily taken from the first
>> Fixes tag I've found in my copy of linux.git):
>>
>> 	a2e459555c5f (2023-08-09; "shmem: stable directory offsets")
>>
>> We could find it, with a trivial command line.  We only even need two
>> characters of the hash:
>>
>> 	$ git log --oneline --after='2023-08-08' --before='2023-08-10' \
>> 	| grep ^a2;
>> 	a2e459555c5f shmem: stable directory offsets
> 
> Why not just git show a2e459555c5f? You're just worried because of
> conflicts? That happens so seldom doing a bit more work to find the
> task is less work than every developer adding a useless date in the tag.
> 
> Even if there are conflicts, git show shows you all the commits that conflict:
> 
>    (random example)
> 
> $ git show cbced
> error: short object ID cbced is ambiguous
> hint: The candidates are:
> hint:   cbced93894d1 commit 2026-02-02 - drm/amd/display: Set CRTC source for DAC using registers
> hint:   cbced0de1ae7 tree
> hint:   cbced35df940 tree
> hint:   cbced38b00f6 tree
> hint:   cbced53122ce tree
> hint:   cbced7856638 tree
> hint:   cbced88f5140 tree
> hint:   cbceda69074d tree
> hint:   cbcedadcc0f9 tree
> hint:   cbced8ff29d4 blob
> hint:   cbcedd7a684b blob
> 
> The above only has one with a subject.
> 
>>
>> No need for a huge script to disambiguate.  This is even typo-resistant,
>> as one could eventually find something that is similar enough, if one
>> had such a field with a typo (in any of the three fields).  You'd be
>> able to search by the other two fields, and two fields should be
>> _usually_ enough for disambiguating, and the third one could corroborate
>> the typo.
>>
>> So, what would you think of having the commit date in commit references
>> such as Fixes tags?
> 
> NAK. I really see no purpose for it, and just adds added noise to the
> Fixes tag. Seriously, your example above:
> 
>   	a2e459555c5f (2023-08-09; "shmem: stable directory offsets")
> 
> Looks horrible compared to:
> 
>   	a2e459555c5f ("shmem: stable directory offsets")
> 
> You are the first one to complain about needing a date here. Who else
> finds this useful in the kernel community? It really feels like it's a
> solution looking for a problem.
> 

Strictly speaking, I've asked about inserting the data before because 
this form:

   a2e459555c5f ("shmem: stable directory offsets", 2023-08-09)

is fairly common within the git development community, but I think that 
community has significantly less tooling around parsing the contents.

The arguments laid out here are pretty compelling that this has no value 
to the Kernel community. If you are worried about disambiguation, adding 
more characters to the hash is preferable (at one point 7 or 8 
characters was sufficient to provide uniqueness, but now we use 12 
characters).

Despite my original comments about liking the format with date, I also 
concur with everyone here that it doesn't make sense to change the 
format. I just modified my global alias and set one different for the 
git projects vs the Linux kernel project. That way my aliases 
(git-whatis and git-fixes) will generate the appropriate format for the 
given project.

Thanks,
Jake

> Sorry,
> 
> -- Steve
>