--abbrev-commit gives longer hash than necessary

Hello, for your possible interest.

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

So it is only this single commit.. but why?

  ?0[steffen@wales ]$ git long1 786d0c9
  786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part handlers..
  ?0[steffen@wales ]$ git long1 786d0c
  786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part handlers..
  ?0[steffen@wales ]$ git long1 786d0
  786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part handlers..
  ?0[steffen@wales ]$ git long1 786d
  786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part handlers..

Not really ambiguous:

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

Ciao!

--steffen

Steffen,

Git commands generally have a 7 character minimum by default when abbreviating hashes, even if fewer characters are still (currently) unique. Per the documentation:

   core.abbrev
       Set the length object names are abbreviated to. If unspecified,
       many commands abbreviate to 7 hexdigits, which may not be enough
       for abbreviated object names to stay unique for sufficiently long
       time.

You may be able to set core.abbrev to a smaller value to get even shorter hashes, but the shorter you go the more likely you are to find once-unique hashes no longer are, as your repository grows over time. The default isn't just about what's likely to be unique now; it's about what's likely to stay unique for a period of time.

Hope this helps! Bryan Turner

On Thu, Jun 30, 2016 at 12:38 PM, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:

Hmhm.

Bryan Turner <bturner@atlassian.com> wrote:

You now support git too.

But say, is that you with the "stay away from the storage backend if you don't have a glue!", long ago on the Mercurial list??? Ha! See how important knowledge of an aggressively garbage-collected storage backend is. I always knew that! Ciao.

--steffen

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

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.

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

-Peff

Hello Jeff!

Jeff King <peff@peff.net> wrote:
 |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:

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

Ah!  That indeed explains it, i didn't know that!

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

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

It clashes a file blob:

  ?0[steffen@wales ]$ git rev-list --objects --all | grep ^786d0c9
  786d0c9c88e5d69eba603e3ed75d1f9cc6ec4e81
  786d0c9d09aaf4107bcaf6c201307ed9db205df5 dotlock.c

Thanks for the explanation! It seems the left side of my brain degenerates faster than the right one. Uff. How lucky i am! Ciao.

--steffen