On Thu, Jun 14 2018, Junio C Hamano wrote:
> Æ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. Yes, it's a trade-off, but just because something is a trade-off doesn't make it useless. Aside from the feature I'm proposing, the same thing applies to the short SHA-1 currently. My ~1k commit dotfiles has 7 characters, but linux.git has 12. Does that make printing the short SHA-1 at all useless and we should just fall back to 40 characters if it's say >= 12? No. 12 is still better than 40, but if we could get away with it 10 would be better than 12. Right now the "get away with it" calculation is a hardcoded constant, this makes it configurable. The reason to make it configurable is because you may want more future proof *or* less future-proof SHA-1s depending on the use-case. Printing a longer SHA-1 has a cost, including but not limited to: * Remembering it for a short time * Seeing it on one screen and typing it into another computer manually * `git log --oneline` output in a terminal where horizontal space is at a premium
