Re: --abbrev-commit gives longer hash than necessary

From: Jeff King <peff@peff.net>
Date: Jul 1, 2016, 06:22 UTC
Message-ID: <20160701062247.GB5358@sigill.intra.peff.net>
In-Reply-To: <20160630193845.TbelqPPHx%steffen@sdaoden.eu>

On Thu, Jun 30, 2016 at 09:38:45PM +0200, Steffen Nurpmeso wrote:

Show 11 quoted lines

> For some time (currently with 2.9.0) know see that a single commit
> gives a longer hash than necessary, even though there is no
> ambiguity:
> 
>   ?0[steffen@wales ]$ git longca|
>   awk 'BEGIN{l7=0;l8=0}\
>     /^[[:alnum:]]{7} /{++l7;next}\
>     /^[[:alnum:]]{8} /{++l8;print}\
>   END{print "L7 " l7 " L8 " l8}'
>   786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part handlers..
>   L7 3364 L8 1

I don't know what your "git longca" alias is, but presumably it's running "git log". That will show just _commit_ hashes, but the abbreviation code will consider all objects.

There are some places you can use an abbreviated sha1 that know they are looking for a commit, but most places will generally complain if there is ambiguity between a blob and commit (e.g., "git show $foo").

It's also presumably just traversing HEAD, so it would miss commits on other branches.

>   ?0[steffen@wales ]$ git long|cut -f1 -d' '|grep ^786
>   786d0c9c
>   786f219

Try "git rev-list --objects --all | grep ^786d0c9".

-Peff