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

On Wed, Feb 25, 2026 at 01:56:02AM +0100, Alejandro Colomar wrote:
>Steven wrote (Fri, 10 Jan 2025 08:03:31 -0500):
>> How can it lead to misjudgment? If you have two or more hashes matching, do
>> you really think they'll have the same subjects?
>
>The possibility isn't zero.  Statistically, it's quite low.  However,
>it's non-zero.
>
>$ git log --format=tformat:'%s' | sort | uniq -c | sort | tail
>    248 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>    263 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
>    275 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>    293 Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
>    314 Merge branch 'akpm' (patches from Andrew)
>    315 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
>    318 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
>    324 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>    369 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
>    670 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>$ git log --format=tformat:'%s' | grep -v ^Merge | sort | uniq -c | sort | tail
>grep: (standard input): binary file matches
>     22 drm/amd/display: Clean up some inconsistent indenting
>     25 Auto-update from upstream
>     26 [ARM] Update mach-types
>     26 pmdomain: Merge branch fixes into next
>     30 s390: update defconfigs
>     32 tools arch x86: Sync the msr-index.h copy with the kernel sources
>     38 [SPARC64]: Update defconfig.
>     52 mmc: Merge branch fixes into next
>     59 drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()
>     62 batman-adv: Start new development cycle
>
>Subjects repeat every now and then, and the entropy in some subjects is
>actually quite low.
>
>If you include the commit date in a Fixes tag, then you preclude the
>entire possibility of a commit reference clash, because you won't have
>two patches committed in the same date with the same subject and same
>hash (unless you *really* try)

The probability of a collision where two commits share both the same
abbreviated SHA1 and the same subject line is so astronomically low that it's
not a realistic concern.

For context, Linus himself pushed back on merely extending the 12-character
SHA1 abbreviation to 13. A change that wouldn't even break existing scripts.
Yet the proposal here is to introduce an entirely new date parameter that's
incompatible with the current format, all to address a scenario that is
unlikely in practice.

-- 
Thanks,
Sasha