1

What defines the the ideal length of a short commit hash?

CI/CD providers surprisingly often hard-code the idea that a "short commit hash is 7-digit long"; I am working with a repository, where a 7-long hash is often ambiguous.

git rev-parse --short HEAD (without explicitly provided "how short") returns a short hash which I can then use everywhere and does remain unique within the repositry.

How does git do that?

Based on the answer to that, I hope I could decude the answers for my more use-case specific questions I have:

  • Can I determine this optimal length without checking out the code? [edit: as in through some APIs of providers such as github/gitlab/bitbucket/...]
  • Can even git calculate this given a shallow checkout?
ifroz
  • 103
  • 3
  • 6
  • 2
    The discussion [here](https://stackoverflow.com/q/18134627/147356) is probably relevant. In particular, I think that [this answer](https://stackoverflow.com/a/42567312/147356) may directly address your question. – larsks Feb 16 '23 at 15:49
  • "Git is smart enough to figure out what commit you’re referring to if you provide the first few characters of the SHA-1 hash, as long as that partial hash is at least four characters long and unambiguous; that is, no other object in the object database can have a hash that begins with the same prefix." https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection – Adrian J. Moreno Feb 16 '23 at 15:49
  • 3
    Does this answer your question? [How much of a git sha is \*generally\* considered necessary to uniquely identify a change in a given codebase?](https://stackoverflow.com/questions/18134627/how-much-of-a-git-sha-is-generally-considered-necessary-to-uniquely-identify-a) – Adrian J. Moreno Feb 16 '23 at 15:51

0 Answers0