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).
