Git commit checksums

[IHateMyJob2004]

Git uses checksums for versioning. Specifically, SHA-1 which is 160 bits or 20 bytes.

Why is it that on commit, the checksum returned is 7 characters of hex? That's only 28 bits.

So what exactly is that hashcode that commit is providing?

From the pro git documentation:
Now you’ve created your first commit! You can see that the commit has given
you some output about itself: which branch you committed to (master),
what SHA-1 checksum the commit has (463dc4f), how many files were
changed, and statistics about lines added and removed in the commit. - page 55 of version 2.25 of the PDF file

The underlined statement is a contradiction.

EDIT: I think I found out ... commit only gives the last 7 hex characters (for some stupid reason)

 

[Cogman]

Git allows you to shorthand the commit hashcode. Checkout the git log on any git repository and you will see that it is the full 20 bytes long. Most of the time (like 90% of the time) the last seven characters is plenty to uniquely identify a commit.

 

[IHateMyJob2004]

Git allows you to shorthand the commit hashcode. Checkout the git log on any git repository and you will see that it is the full 20 bytes long. Most of the time (like 90% of the time) the last seven characters is plenty to uniquely identify a commit.

Agree that the last 7 is good enough but I think it is stupid. It's like asking John Doe what his name is and to write it down and he just writes down "oe". It can only lead to confusion, not clarity.

 

[Markbnj]

Agree that the last 7 is good enough but I think it is stupid. It's like asking John Doe what his name is and to write it down and he just writes down "oe". It can only lead to confusion, not clarity.

How often do people really need to refer to those hashes?

 

[purbeast0]

i use TortoiseGit for 99% of my git stuff (on windows at least, use GitX on my mac at home). it displays all characters in the sha-1 when viewing the logs and committing stuff.

 

[dave_the_nerd]

Isn't it the first seven characters and not the last seven? (Instead of John Doe => oe, it'd be John Doe = Jo)

Incidentally, when you checkout, you can use use the abbreviated hash as well.

It's just a human interface convenience.

 

[IHateMyJob2004]

As for the hash. Show it all or show nothing. Partial is stupid. The power of SHA-1 is that collisions would be a statistical anomaly worthy of a movie. Using a piece of the hash ... not really movie material.

unique combinations of 160 bits:
1.4615016373309029182036848327163e+48

That's 25 printable characters.
25 printable characters = 2.7738957312183406810942176067978e+49 combinations

85 printable characters would suffice to eliminate some of the questionable ones like space and double quote and quote.

It's not like you are going to commit 7 random characters to memory anyway. It's a ctrl-c ctrl-v job any way you look at it.

 

[Merad]

This is a silly complaint. If you want to use the full SHA then use it. The short version is a convenience, nothing more (you can use as few as 4 digits). If your truncated SHA is ambiguous git will make you enter more digits. Also, git will always show you a truncated SHA that is unique. The linux kernel (with nearly half a million commits) is up to showing 12 digit SHAs from what I've read.

For the typical repo 7 digits gives odds of collision are ludicrously small. Something like three thousandths of a percent chance of a collision on 7 digits even with 10,000 commits in your repo.

 

[dave_the_nerd]

This is a silly complaint.

Getting excessively worked up over objectively silly complaints is how I spot the good programmers.

 

[Markbnj]

Getting excessively worked up over objectively silly complaints is how I spot the good programmers.

Ha, depends. If you're trying to get from this mountain to the next mountain the guy going in circles with his eyes on something at his feet isn't always helping.

 

[DaveSimmons]

FYI, be sure to update your client:

http://arstechnica.com/security/201...-malicious-code-execution-on-client-machines/