{"thread":{"id":"42759","subject":"--abbrev-commit gives longer hash than necessary","startedAt":"2016-06-30T19:48:15Z","lastAt":"2016-07-01T10:47:19Z","messageCount":5,"participants":["Steffen Nurpmeso","Bryan Turner","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"290609","messageId":"20160630193845.TbelqPPHx%steffen@sdaoden.eu","threadId":"42759","inReplyTo":null,"subject":"--abbrev-commit gives longer hash than necessary","fromName":"Steffen Nurpmeso","fromEmail":"steffen@sdaoden.eu","sentAt":"2016-06-30T19:38:45Z","receivedAt":"2016-06-30T19:48:15Z","isPatch":false,"sender":{"key":"steffen@sdaoden.eu","avatar":"https://gravatar.com/avatar/d49e696effa4b8f04abdee3c3567a1638260b8fa05df4f389a373db04fc8a1b3?d=mp&s=160"},"body":"Hello, for your possible interest.\n\nFor some time (currently with 2.9.0) know see that a single commit\ngives a longer hash than necessary, even though there is no\nambiguity:\n\n  ?0[steffen@wales ]$ git longca|\n  awk 'BEGIN{l7=0;l8=0}\\\n    /^[[:alnum:]]{7} /{++l7;next}\\\n    /^[[:alnum:]]{8} /{++l8;print}\\\n  END{print \"L7 \" l7 \" L8 \" l8}'\n  786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part handlers..\n  L7 3364 L8 1\n\nSo it is only this single commit.. but why?\n\n  ?0[steffen@wales ]$ git long1 786d0c9\n  786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part handlers..\n  ?0[steffen@wales ]$ git long1 786d0c\n  786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part handlers..\n  ?0[steffen@wales ]$ git long1 786d0\n  786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part handlers..\n  ?0[steffen@wales ]$ git long1 786d\n  786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part handlers..\n\nNot really ambiguous:\n\n  ?0[steffen@wales ]$ git long|cut -f1 -d' '|grep ^786\n  786d0c9c\n  786f219\n\nCiao!\n\n--steffen\n"},{"id":"290610","messageId":"CAGyf7-E0VbkCC29y=OuNHL5_KA=qoXEsrChxvXcGmfZ_CjTzqQ@mail.gmail.com","threadId":"42759","inReplyTo":"20160630193845.TbelqPPHx%steffen@sdaoden.eu","subject":"Re: --abbrev-commit gives longer hash than necessary","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2016-06-30T20:14:41Z","receivedAt":"2016-06-30T20:22:59Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"Steffen,\n\nGit commands generally have a 7 character minimum by default when\nabbreviating hashes, even if fewer characters are still (currently)\nunique. Per the documentation:\n\n   core.abbrev\n       Set the length object names are abbreviated to. If unspecified,\n       many commands abbreviate to 7 hexdigits, which may not be enough\n       for abbreviated object names to stay unique for sufficiently long\n       time.\n\nYou may be able to set core.abbrev to a smaller value to get even\nshorter hashes, but the shorter you go the more likely you are to find\nonce-unique hashes no longer are, as your repository grows over time.\nThe default isn't just about what's likely to be unique now; it's\nabout what's likely to stay unique for a period of time.\n\nHope this helps!\nBryan Turner\n\nOn Thu, Jun 30, 2016 at 12:38 PM, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:\n> Hello, for your possible interest.\n>\n> For some time (currently with 2.9.0) know see that a single commit\n> gives a longer hash than necessary, even though there is no\n> ambiguity:\n>\n>   ?0[steffen@wales ]$ git longca|\n>   awk 'BEGIN{l7=0;l8=0}\\\n>     /^[[:alnum:]]{7} /{++l7;next}\\\n>     /^[[:alnum:]]{8} /{++l8;print}\\\n>   END{print \"L7 \" l7 \" L8 \" l8}'\n>   786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part handlers..\n>   L7 3364 L8 1\n>\n> So it is only this single commit.. but why?\n>\n>   ?0[steffen@wales ]$ git long1 786d0c9\n>   786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part handlers..\n>   ?0[steffen@wales ]$ git long1 786d0c\n>   786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part handlers..\n>   ?0[steffen@wales ]$ git long1 786d0\n>   786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part handlers..\n>   ?0[steffen@wales ]$ git long1 786d\n>   786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part handlers..\n>\n> Not really ambiguous:\n>\n>   ?0[steffen@wales ]$ git long|cut -f1 -d' '|grep ^786\n>   786d0c9c\n>   786f219\n>\n> Ciao!\n>\n> --steffen\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"290632","messageId":"20160701062247.GB5358@sigill.intra.peff.net","threadId":"42759","inReplyTo":"20160630193845.TbelqPPHx%steffen@sdaoden.eu","subject":"Re: --abbrev-commit gives longer hash than necessary","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-07-01T06:22:47Z","receivedAt":"2016-07-01T06:29:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jun 30, 2016 at 09:38:45PM +0200, Steffen Nurpmeso wrote:\n\n> For some time (currently with 2.9.0) know see that a single commit\n> gives a longer hash than necessary, even though there is no\n> ambiguity:\n> \n>   ?0[steffen@wales ]$ git longca|\n>   awk 'BEGIN{l7=0;l8=0}\\\n>     /^[[:alnum:]]{7} /{++l7;next}\\\n>     /^[[:alnum:]]{8} /{++l8;print}\\\n>   END{print \"L7 \" l7 \" L8 \" l8}'\n>   786d0c9c [mimepipe.2] send.c:sendpart(): force iconv(3)+ for TEXT part handlers..\n>   L7 3364 L8 1\n\nI don't know what your \"git longca\" alias is, but presumably it's\nrunning \"git log\". That will show just _commit_ hashes, but the\nabbreviation code will consider all objects.\n\nThere are some places you can use an abbreviated sha1 that know they are\nlooking for a commit, but most places will generally complain if there\nis ambiguity between a blob and commit (e.g., \"git show $foo\").\n\nIt's also presumably just traversing HEAD, so it would miss commits on\nother branches.\n\n>   ?0[steffen@wales ]$ git long|cut -f1 -d' '|grep ^786\n>   786d0c9c\n>   786f219\n\nTry \"git rev-list --objects --all | grep ^786d0c9\".\n\n-Peff\n"},{"id":"290653","messageId":"20160701104131.HERNyrxUU%steffen@sdaoden.eu","threadId":"42759","inReplyTo":"20160701062247.GB5358@sigill.intra.peff.net","subject":"Re: --abbrev-commit gives longer hash than necessary","fromName":"Steffen Nurpmeso","fromEmail":"steffen@sdaoden.eu","sentAt":"2016-07-01T10:41:31Z","receivedAt":"2016-07-01T10:41:03Z","isPatch":false,"sender":{"key":"steffen@sdaoden.eu","avatar":"https://gravatar.com/avatar/d49e696effa4b8f04abdee3c3567a1638260b8fa05df4f389a373db04fc8a1b3?d=mp&s=160"},"body":"Hello Jeff!\n\nJeff King <peff@peff.net> wrote:\n |On Thu, Jun 30, 2016 at 09:38:45PM +0200, Steffen Nurpmeso wrote:\n |> For some time (currently with 2.9.0) know see that a single commit\n |> gives a longer hash than necessary, even though there is no\n |> ambiguity:\n\n |I don't know what your \"git longca\" alias is, but presumably it's\n |running \"git log\". That will show just _commit_ hashes, but the\n |abbreviation code will consider all objects.\n\nAh!  That indeed explains it, i didn't know that!\n\n |There are some places you can use an abbreviated sha1 that know they are\n |looking for a commit, but most places will generally complain if there\n |is ambiguity between a blob and commit (e.g., \"git show $foo\").\n\n |Try \"git rev-list --objects --all | grep ^786d0c9\".\n\nIt clashes a file blob:\n\n  ?0[steffen@wales ]$ git rev-list --objects --all | grep ^786d0c9\n  786d0c9c88e5d69eba603e3ed75d1f9cc6ec4e81\n  786d0c9d09aaf4107bcaf6c201307ed9db205df5 dotlock.c\n\nThanks for the explanation!\nIt seems the left side of my brain degenerates faster than the\nright one.  Uff.  How lucky i am!\nCiao.\n\n--steffen\n"},{"id":"290654","messageId":"20160701104546.U6-cRyFzI%steffen@sdaoden.eu","threadId":"42759","inReplyTo":"CAGyf7-E0VbkCC29y=OuNHL5_KA=qoXEsrChxvXcGmfZ_CjTzqQ@mail.gmail.com","subject":"Re: --abbrev-commit gives longer hash than necessary","fromName":"Steffen Nurpmeso","fromEmail":"steffen@sdaoden.eu","sentAt":"2016-07-01T10:45:46Z","receivedAt":"2016-07-01T10:47:19Z","isPatch":false,"sender":{"key":"steffen@sdaoden.eu","avatar":"https://gravatar.com/avatar/d49e696effa4b8f04abdee3c3567a1638260b8fa05df4f389a373db04fc8a1b3?d=mp&s=160"},"body":"Hmhm.\n\nBryan Turner <bturner@atlassian.com> wrote:\n\nYou now support git too.\n\nBut say, is that you with the \"stay away from the storage backend\nif you don't have a glue!\", long ago on the Mercurial list???\nHa!\nSee how important knowledge of an aggressively garbage-collected\nstorage backend is.  I always knew that!\nCiao.\n\n--steffen\n"}]}