git itself does not use a fixed size abbreviation but determines the length necessary with the birthday paradox formula. It just happens to be seven characters most of the time, because most repos are small.
This is just for the abbreviated hash which git uses only for specific cases like display in the git log and similar, where it is a user experience improvement and relatively safe.
I know. I don’t understand why the Linux Kernel uses a hard-coded abbreviation instead of just letting Git figure out how long it should be (edited my comment now).
The length of the required abbreviation grows over time, while content you put in commit messages sticks around. Meaning a commit done in year 2005 may have gotten away with "Fixes: abcd" and was unambiguous at that time, whereas after 20 years of growth, there could now be multiple other commits with that prefix.
By that logic, any length of abbreviation will eventually fail if stored for a long time, those abbreviations should be seen as temporary for user interaction only. For the "Fixes:" footer they should have gone with full hash, it's hidden away in the footer so it doesn't disrupt anyone. Aanyone interacting with it will double click to copy it regardless if it is 8 or 40 characters long. Abbreviating it simply adds no value.
So as noted you can configure the length, but you can't actually adjust the probability used by the auto-length formula.
The formula calculates how many bits are needed to store the approximate number of objects, then uses twice that many bits, rounding up.
For example, at 16000 objects git is still using the minimum length of 7 characters. But at 17000 objects it now takes 15 bits to store the object count, so it wants 30 bits of hash, which means 8 characters.
This is just for the abbreviated hash which git uses only for specific cases like display in the git log and similar, where it is a user experience improvement and relatively safe.