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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 26, 2016, 03:46 UTC
Message-ID: <xmqq37knwcf4.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CA+55aFy0_pwtFOYS1Tmnxipw9ZkRNCQHmoYyegO00pjMiZQfbg@mail.gmail.com>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 8 quoted lines

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