Re: [PATCH] find_unique_abbrev(): honor caller-supplied "len" better

Junio C Hamano <gitster@pobox.com> writes:

Yuck, this is showing my total non-understanding of statistics and secure hashing. The example does not mean the next object we will create in git.git project somehow magically is more likely to have 979 prefix than 83c prefix. In other words, 979f7929 is much less likely to collide with new objects than 83c3c, simply because it has 4 more digits in it (making the likelyhood of collision with the next one by four orders of magnitude in base-16), the likelyhood does not depend on what other objects happen to share the same prefix right now, and adding one digits to each would make it 1/16 less likely to have collision relative to the likelyhood with their current length.

In any case, if we want to protect abbreviations we generate today from future collisions, the only sane thing to do is to give sufficiently long "len" that is computed globally by taking the total number of objects into account. We should consider the loop in find_unique_abbrev that makes sure that prefix truncated to len is unique, and increments until the result becomes unique, merely a last-ditch thing, not contributing to futureproofing. Even though adding 1 to make it minimally unique as we have always did before the abbrevguard patch has the same "that 1 extra has different effectiveness for protecting against future collisions, depending on how long the base string is" issue, we cannot get away by adding less than 1 character, and adding more doesn't make it better.

So let's scrap the abbrevguard thing. I somehow thought that I already took your "make DEFAULT_ABBREV tweakable" patch, but apparently I didn't. That one is the real fix to the issue of futureproofing.