Subject: Re: Changing the default for "core.abbrev"?

From: Junio C Hamano <[email-masked]>
Date: Sun, 25 Sep 2016 20:46:39 -0700

Linus Torvalds <[email-masked]> writes:

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

I am not quite sure how good any new default would be, though.  Just
like any timeout is not long enough for somebody, growing projects
will eventually hit whatever abbreviation length they start with.

Even if we bump it to 12 for everybody, majority of projects at
GitHub would probably be just wasting 5 more hexdigits in addition
to whatever they are already wasting.  The kernel folks will keep
having the problem of having harder time looking up objects referred
to by ancient commits no matter what the new default is anyway, and
then they will again regret we didn't bump it to 16 in year 2016 in
several decades; by that time both of us are probably retired so it
may no longer be our problems, though ;-)

I am not opposed to bump the default to 12 or whatever, but I
suspect any lengthening today may need to be accompanied by a tool
support that finds the set of objects that are reachable from a
commit whose names begin with non-unique abbreviations that appear
in the commit log message. Assuming that it is very hard to refer to
future objects in the log message you write today, such a tool may
find a single object that used to be the unique instance of that
abbreviation back then, and with reachability bitmap support, it may
not be too expensive to run.