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
