> As Peff said, responding in a thread started by Linus's suggestion
> to raise the default abbreviation to 12 hexdigits:
> I actually think "12" might be sane for a long time. That's 48 bits of
> sha1, so we'd expect a 50% change of a _single_ collision at 2^24, or 16
I know it's quoted, but still.
> million. The biggest repository I know about (in number of objects) is
> the one holding all of the objects for all of the forks of
> torvalds/linux on GitHub. It's at about 15 million objects.
> Which _seems_ close, but remember that's the size where we expect to see
> a single collision. They don't become common until much later (I didn't
> compute an exact number, but Linus's 16x sounds about right). I know
> that the growth of the kernel isn't really linear, but I think the need
> to bump to "13" might not just be decades, but possibly a century or
> So 12 seems reasonable, and the only downside for it (or for "13", for
> that matter) is a few extra bytes. I dunno, maybe people will really
> hate that, but I have a feeling these are mostly cut-and-pasted anyway.
I for one raise my hand in protest...
"few extra bytes" is not the only downside, and it's not at all about
how many characters are copy-and-pasted. In my opinion it's much more
important that this change wastes 5 columns worth of valuable screen
real estate e.g. for 'git blame' or 'git log --oneline' in projects
that don't need it and certainly won't ever need it.
Sure, users working on smaller repos are free to reset core.abbrev to
its original value. I don't have any numbers, of course, but I
suspect that there are many more smaller repos out there that this
change will affect disadvantageously, than there are large repos for
which it's beneficial.
> And this does exactly that.
> Keep the tests working by explicitly asking for the old 7 hexdigits
> setting in the fake system-wide configuration file used for tests.
> Signed-off-by: Junio C Hamano <gits...@pobox.com>