Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: > On Wed, Jun 13 2018, Junio C Hamano wrote: > >> Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: >> >>> E.g. here's a breakdown of my dotfiles repo: >>> >>> $ git -c core.abbrev=4 log --pretty=format:%h|perl -nE 'chomp;say >>> length'|sort|uniq -c|sort -nr >>> 784 4 >>> 59 5 >>> 7 6 >>> >>> I don't have a single commit that needs 7 characters, yet that's our >>> default. This is a sane trade-off for the kernel, but for something >>> that's just a toy or something you're playing around with something >>> shorter can make sense. >>> >>> SHA-1s aren't just written down, but also e.g. remembered in wetware >>> short-term memory. >> >> That's a fine example of what I called "supporting absurdly small >> absolute values like 4"; I still do not see why you want "negative >> relative values" from that example. > > Because hardcoding -2 is very different than setting it to 5, because > the -2 will scale to the size of the repository, but 5 is just 7-2 where > 7 is our default value. > > So, in general if you want less future proof hashes by some > probabilistic metric (whether you use core.validateAbbrev or not) you'd > use -2 or -3, just like you might use +2 or +3 if you'd like to have > more future-proof hashes (especially with core.validateAbbrev=true).
That still does not make much sense to me at all. I do agree that something shorter than the default 7 may be more appropriate for our wetware short-term memory, and it would make sense to grow the "riskier to collide than the default heuristics but more memorable" variant as the project grows, _ONLY_ _IF_ our wetware short-term memory scales with the project we happen to be working on. But our wetware does not scale with the project we work on; at least mine does not. So...
