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
