5 ms·

Beautify the Git commit hash (have a look at the commit hashes on the right)

39 points by vog 15y ago

davvid 15y ago
Interesting. This script modifies the commit timestamp until the commit object hashes to a SHA-1 that starts with a prefix specified on the command-line. It seems like it was used on the repo itself with prefixes of 0001, 0002, 0003. $ ./beautify_git_hash.py 0001 I wonder if this somehow increases the probability of a hash collision, if only ever so slightly? In any case, it's a neat hack! The script prints a suggested "git commit --amend" command so don't run the suggestion if you've already pushed the head of your branch.
- davvid 15y ago
  There is another downside to keep in mind. git commands accept the shortest unambiguous SHA-1 prefix instead of requiring you to specify the entire thing. Usually the first 7 characters or so will do, even on fairly large projects. Using this script too often may force you to specify more characters to get past the prefix being identical on too many commits.
  - ajross 15y ago
    Exactly! That's exactly what I was thinking reading this... it's a bad thing, not a feature. Why on earth would anyone do this to their repo willingly? This is visual aesthetics run amok, in the hands of someone who doesn't understand what the point of that hash value was. Ouch.
    - vog 15y ago
      You are missing the fact that this is a toy project and by no means meant seriously. Apart from that, of course you should use sensible prefixes like "0001", "0002", etc. and not use the same prefix for all commits.
- kmm 15y ago
  SHA-1 has a digest size of 160 bits. The first two bytes of these beautified hashes are predetermined, which lowers the size to 144 bits. For a more than 50% chance of a collision, more than 4 sextillion hashes[1] would have to be generated, compared to 1 septillion hashes[2] for the normal digest. A difference of an order of a magnitude, yet absolutely nothing to be worried about. Collisions are vastly more likely to be caused by a stray cosmic ray than actual chance. [1] 2^(144/2) ~= 7e21 [2] 2^(160/2) ~= 1e24
  - vog 15y ago
    This is only true if you use the same prefix for all commits. However, the script takes the prefix as argument, which allows you to use prefixed like 0001, 0002, etc. Apart from that, this is a toy project and by no means meant seriously.
    - kmm 15y ago
      I didn't take it seriously of course, I just saw this question and I was myself curious what the chances of a birthday collision actually are.
- CJefferson 15y ago
  While it does increase the chances of a hash collision, note that no-one has ever been able to find a SHA-1 collision, out of all the projects that use it everywhere. If you find a SHA-1 collision, by any method, you will become very, very famous. It will probably be worth having a broken git repository.
- vog 15y ago
  (I'm the author of this little toy script) Some small corrections: The script is able to set 5 digits, not 4. The prefixes in the examples are actually 0001a, 0002a, etc. I added the trailing "a" to make the numbers more readable. Otherwise you would get hashes like 00015... which would look awkward. So I'm using the "a" as a kind of separator. Also, the script refuses to change timestamps by more than 30 minutes. So changing only the committer timestamp would allow you to set only 2-3 hash digits. That's why I'm also changing the author timestamp, which leads to enough possible combinations to set about 5 hash digits. (Unless you're unlucky, because there's always a rest possibility for failure in this kind of algorithms.) BTW, this program has been inspired by BitCoin's proof of work concept.
srd 15y ago
While the beauty may be in the eye of the beholder, for X11 based systems this is actually a step back. I used to be able to highlight and paste the hashes, now the hash string is "hidden" inside a button where text link would do. Sure, as an ugly, kludgy workaround there is the flash-based "copy to clipboard" button, but that only works with ctrl-v pasting, not the middle mouse button. Good luck pasting that into an xterm. So it's either copy-type or click on the link and find the sha in text form on the resulting page. I found myself using git log a lot more frequently during the past few days.
- piotrSikora 15y ago
  OP didn't mean GitHub changes, but "beautiful" commit ids (0001..., 0002..., 0003..., etc).
- LukeShu 15y ago
  It's referring the the hashes themselves (0001..., 0002..., 0003...), not the html/css GitHub uses.
- jack12 15y ago
  like everyone else said, the link's not about the UI. But on that subject, autocutsel (http://www.nongnu.org/autocutsel/ http://www.nongnu.org/autocutsel/) can keep all of your X11 clipboards synchronized, so that anything copied to the clipboard can be MMB pasted, and anything selected with the LMB can be Ctrl-V pasted.
- Estragon 15y ago
  > Good luck pasting that into an xterm. Try Ctrl-Shift-V.
zbowling 15y ago
really need this sequencing hash hack when we have date/timestamps for sequence?
- davvid 15y ago
  Righty-o, it's purely for fun. @vog: merge my pull request, man. There's a post-commit hook in there. I think we finally solved the SHA-1 vs r#### argument ;-) https://github.com/davvid/beautify_git_hash/commits/master https://github.com/davvid/beautify_git_hash/commits/master
  - vog 15y ago
    Sorry for not having accepted your patches, but I explained the reasons in a comment on your pull request: https://github.com/vog/beautify_git_hash/pull/1 https://github.com/vog/beautify_git_hash/pull/1
jrockway 15y ago
Git history is not linear, so numbering commits sequentially is meaningless. Git already has a mechanism for naming commits, anyway. They are called "tags".
- JeremyBanks 15y ago
  Git's going to have built-in "generation numbers" soon. http://permalink.gmane.org/gmane.comp.version-control.git/177146 http://permalink.gmane.org/gmane.comp.version-control.git/17... edit: jacknagel points out that they actually didn't go with this after all. Insted: https://github.com/git/git/commit/ffc4b8012d9a4f92ef238ff72c0d15e9e1b402ed https://github.com/git/git/commit/ffc4b8012d9a4f92ef238ff72c...
  - jrockway 15y ago
    So imagine your history looks like this: __C__ / \ A---B---D A is commit number one. D is commit number three. If B is two, then what is C? Assuming you can come up with a consistent view when all the information about the branch topology is available, what about when people have disconnected branches? How do you avoid duplicate generation numbers? If you can't avoid duplicate generation numbers, what's the point of having them? "Fixed in commit 2." Great, which commit 2 did you mean?
    - JeremyBanks 15y ago
      You have duplicates, B and C would have the same generation number. It just represents length of the longest path from the root commit. This is already calculated internally to optimize several operations, so they were considering making it part of the commit data. It often won't uniquely identify commits, but revision numbers in SVN are also sometimes used imprecisely ("oh, it was around R1500"), so I think it would have value.
      - jrockway 15y ago
        Yeah, but you know people want this so they can write things in their bug tracker like "fixed in r1232" instead of "fixed in 2c4d96d1dc2d12afd486561329a9a7b74d4ae110".

39 points by vog 15y ago

Interesting. This script modifies the commit timestamp until the commit object hashes to a SHA-1 that starts with a prefix specified on the command-line. It seems like it was used on the repo itself with prefixes of 0001, 0002, 0003. $ ./beautify_git_hash.py 0001 I wonder if this somehow increases the probability of a hash collision, if only ever so slightly? In any case, it's a neat hack! The script prints a suggested "git commit --amend" command so don't run the suggestion if you've already pushed the head of your branch.

davvid 15y ago
There is another downside to keep in mind. git commands accept the shortest unambiguous SHA-1 prefix instead of requiring you to specify the entire thing. Usually the first 7 characters or so will do, even on fairly large projects. Using this script too often may force you to specify more characters to get past the prefix being identical on too many commits.
- ajross 15y ago
  Exactly! That's exactly what I was thinking reading this... it's a bad thing, not a feature. Why on earth would anyone do this to their repo willingly? This is visual aesthetics run amok, in the hands of someone who doesn't understand what the point of that hash value was. Ouch.
  - vog 15y ago
    You are missing the fact that this is a toy project and by no means meant seriously. Apart from that, of course you should use sensible prefixes like "0001", "0002", etc. and not use the same prefix for all commits.
kmm 15y ago
SHA-1 has a digest size of 160 bits. The first two bytes of these beautified hashes are predetermined, which lowers the size to 144 bits. For a more than 50% chance of a collision, more than 4 sextillion hashes[1] would have to be generated, compared to 1 septillion hashes[2] for the normal digest. A difference of an order of a magnitude, yet absolutely nothing to be worried about. Collisions are vastly more likely to be caused by a stray cosmic ray than actual chance. [1] 2^(144/2) ~= 7e21 [2] 2^(160/2) ~= 1e24
- vog 15y ago
  This is only true if you use the same prefix for all commits. However, the script takes the prefix as argument, which allows you to use prefixed like 0001, 0002, etc. Apart from that, this is a toy project and by no means meant seriously.
  - kmm 15y ago
    I didn't take it seriously of course, I just saw this question and I was myself curious what the chances of a birthday collision actually are.
CJefferson 15y ago
While it does increase the chances of a hash collision, note that no-one has ever been able to find a SHA-1 collision, out of all the projects that use it everywhere. If you find a SHA-1 collision, by any method, you will become very, very famous. It will probably be worth having a broken git repository.
vog 15y ago
(I'm the author of this little toy script) Some small corrections: The script is able to set 5 digits, not 4. The prefixes in the examples are actually 0001a, 0002a, etc. I added the trailing "a" to make the numbers more readable. Otherwise you would get hashes like 00015... which would look awkward. So I'm using the "a" as a kind of separator. Also, the script refuses to change timestamps by more than 30 minutes. So changing only the committer timestamp would allow you to set only 2-3 hash digits. That's why I'm also changing the author timestamp, which leads to enough possible combinations to set about 5 hash digits. (Unless you're unlucky, because there's always a rest possibility for failure in this kind of algorithms.) BTW, this program has been inspired by BitCoin's proof of work concept.

srd 15y ago

While the beauty may be in the eye of the beholder, for X11 based systems this is actually a step back. I used to be able to highlight and paste the hashes, now the hash string is "hidden" inside a button where text link would do. Sure, as an ugly, kludgy workaround there is the flash-based "copy to clipboard" button, but that only works with ctrl-v pasting, not the middle mouse button. Good luck pasting that into an xterm. So it's either copy-type or click on the link and find the sha in text form on the resulting page. I found myself using git log a lot more frequently during the past few days.

piotrSikora 15y ago
OP didn't mean GitHub changes, but "beautiful" commit ids (0001..., 0002..., 0003..., etc).
LukeShu 15y ago
It's referring the the hashes themselves (0001..., 0002..., 0003...), not the html/css GitHub uses.
jack12 15y ago
like everyone else said, the link's not about the UI. But on that subject, autocutsel (http://www.nongnu.org/autocutsel/ http://www.nongnu.org/autocutsel/) can keep all of your X11 clipboards synchronized, so that anything copied to the clipboard can be MMB pasted, and anything selected with the LMB can be Ctrl-V pasted.
Estragon 15y ago
> Good luck pasting that into an xterm. Try Ctrl-Shift-V.

zbowling 15y ago

really need this sequencing hash hack when we have date/timestamps for sequence?

davvid 15y ago
Righty-o, it's purely for fun. @vog: merge my pull request, man. There's a post-commit hook in there. I think we finally solved the SHA-1 vs r#### argument ;-) https://github.com/davvid/beautify_git_hash/commits/master https://github.com/davvid/beautify_git_hash/commits/master
- vog 15y ago
  Sorry for not having accepted your patches, but I explained the reasons in a comment on your pull request: https://github.com/vog/beautify_git_hash/pull/1 https://github.com/vog/beautify_git_hash/pull/1

jrockway 15y ago

Git history is not linear, so numbering commits sequentially is meaningless. Git already has a mechanism for naming commits, anyway. They are called "tags".

JeremyBanks 15y ago
Git's going to have built-in "generation numbers" soon. http://permalink.gmane.org/gmane.comp.version-control.git/177146 http://permalink.gmane.org/gmane.comp.version-control.git/17... edit: jacknagel points out that they actually didn't go with this after all. Insted: https://github.com/git/git/commit/ffc4b8012d9a4f92ef238ff72c0d15e9e1b402ed https://github.com/git/git/commit/ffc4b8012d9a4f92ef238ff72c...
- jrockway 15y ago
  So imagine your history looks like this: __C__ / \ A---B---D A is commit number one. D is commit number three. If B is two, then what is C? Assuming you can come up with a consistent view when all the information about the branch topology is available, what about when people have disconnected branches? How do you avoid duplicate generation numbers? If you can't avoid duplicate generation numbers, what's the point of having them? "Fixed in commit 2." Great, which commit 2 did you mean?
  - JeremyBanks 15y ago
    You have duplicates, B and C would have the same generation number. It just represents length of the longest path from the root commit. This is already calculated internally to optimize several operations, so they were considering making it part of the commit data. It often won't uniquely identify commits, but revision numbers in SVN are also sometimes used imprecisely ("oh, it was around R1500"), so I think it would have value.
    - jrockway 15y ago
      Yeah, but you know people want this so they can write things in their bug tracker like "fixed in r1232" instead of "fixed in 2c4d96d1dc2d12afd486561329a9a7b74d4ae110".