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

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.

Sorry,

-- Steve