# --abbrev-commit gives longer hash than necessary 5 messages from 2016-06-30 to 2016-07-01. Participants: Steffen Nurpmeso, Bryan Turner, Jeff King. Thread: https://gitlist.dev/t/42759 ## Steffen Nurpmeso, 2016-06-30 19:38 Subject: --abbrev-commit gives longer hash than necessary Message-ID: <20160630193845.TbelqPPHx%steffen@sdaoden.eu> URL: https://gitlist.dev/e/20160630193845.TbelqPPHx%25steffen%40sdaoden.eu ``` 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 ``` ## Bryan Turner, 2016-06-30 20:14 Subject: Re: --abbrev-commit gives longer hash than necessary Message-ID: URL: https://gitlist.dev/e/CAGyf7-E0VbkCC29y%3DOuNHL5_KA%3DqoXEsrChxvXcGmfZ_CjTzqQ%40mail.gmail.com In-Reply-To: <20160630193845.TbelqPPHx%steffen@sdaoden.eu> ``` 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 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 ``` ## Jeff King, 2016-07-01 06:22 Subject: Re: --abbrev-commit gives longer hash than necessary Message-ID: <20160701062247.GB5358@sigill.intra.peff.net> URL: https://gitlist.dev/e/20160701062247.GB5358%40sigill.intra.peff.net In-Reply-To: <20160630193845.TbelqPPHx%steffen@sdaoden.eu> ``` 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 ``` ## Steffen Nurpmeso, 2016-07-01 10:41 Subject: Re: --abbrev-commit gives longer hash than necessary Message-ID: <20160701104131.HERNyrxUU%steffen@sdaoden.eu> URL: https://gitlist.dev/e/20160701104131.HERNyrxUU%25steffen%40sdaoden.eu In-Reply-To: <20160701062247.GB5358@sigill.intra.peff.net> ``` Hello Jeff! Jeff King 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 ``` ## Steffen Nurpmeso, 2016-07-01 10:45 Subject: Re: --abbrev-commit gives longer hash than necessary Message-ID: <20160701104546.U6-cRyFzI%steffen@sdaoden.eu> URL: https://gitlist.dev/e/20160701104546.U6-cRyFzI%25steffen%40sdaoden.eu In-Reply-To: ``` Hmhm. Bryan Turner 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 ```