Re: --abbrev-commit gives longer hash than necessary
Hmhm. Bryan Turnerwrote: 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 -- 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
Re: --abbrev-commit gives longer hash than necessary
Hello Jeff! Jeff Kingwrote: |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 -- 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
Re: --abbrev-commit gives longer hash than necessary
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
Re: --abbrev-commit gives longer hash than necessary
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 Nurpmesowrote: > 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
--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 -- 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