On Thu, Jun 30, 2016 at 09:38:45PM +0200, Steffen Nurpmeso wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
