The default value for commit abbreviation (environment.c: 19) is seven:

    int minimum_abbrev = 4, default_abbrev = 7;

which back in the dark early days of git was fairly reasonable.

It's probably still a perfectly fine default for lots of projects,
since 7 hex digits is a few hundred million unique values, and you
won't really start to get very many collisions in that until you get
closer to a million objects.

The kernel, these days, is at roughly 5 million objects, and while the
seven hex digits are still often enough for uniqueness (and git will
always add digits *until* it is unique), it's long been at the point
where I tell people to do

    git config --global core.abbrev 12

because even though git will extend the seven hex digits until the
object name is unique, that only reflects the *current* situation in
the repository. With 5 million objects and a very healthy growth rate,
a 7-8 hex digit number that is unique today is not necessarily unique
a month or two from now, and then it gets annoying when a commit
message has a short git ID that is no longer unique when you go back
and try to figure out what went wrong in that commit.

I can just keep reminding kernel maintainers and developers to update
their git config, but maybe it would be a good idea to just admit that
the defaults picked in 2005 weren't necessarily the best ones
possible, and those could be bumped up a bit?

I think I mentioned this some time ago, and it's not a huge deal, but
I thought I'd just mention it again because it came up again today for



Reply via email to