--abbrev-commit gives longer hash than necessary

--abbrev-commit gives longer hash than necessary

[Steffen Nurpmeso]

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

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

[Bryan Turner]

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:
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Jeff King]

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

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

[Steffen Nurpmeso]

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

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

[Steffen Nurpmeso]

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