Presumably the problem is that these tools only take the abbreviated hash into account. Not also the subject:

    <abbrev. hash> ("<subject>")

You also have another data point. You only need to search in the history from the commit that you are reading. Assuming that the "Fixes" commit is an ancestor of the commit whose commit footer you are reading.

I always just assumed that tools would take all the data into account. Which means that you both need to collide with the abbreviated hash as well as the subject. Now I don't do that since I just copy-paste the hash, but I would quickly notice in case the subject is different (and likely the commit message and the diff just look irrelevant).

I don't understand why the Linux Kernel has this hard-coded rule[2] -- again, you were going to get collisions eventually, so the tools should have just taken all the data into account (at least the subject) from the start. The recommendation in the Git project is to use `git show -s --pretty=reference`, without any fiddling with the abbreviation:

    <abbrev. hash> (subject, ISO date)

Although the Git maintainer uses `--abbrev=8` since git-show will just use a longer abbreviation in case the output would be ambiguous[1].

They could have used this instead if they wanted simpler, future-proof tooling:

    Fixes: <full hash>

Just like tools like git-revert and git-cherry-pick do.

[1]: https://lore.kernel.org/git/xmqq34j5h7v9.fsf@gitster.g/

[2]: Edit: hard-coded as opposed to Git just figuring out how long the abbreviation should be based on how many objects there are.