

Beautify the Git commit hash (have a look at the commit hashes on the right) - vog
https://github.com/vog/beautify_git_hash/commits/master

======
davvid
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.

~~~
kmm
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
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
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.

------
jrockway
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
Git's going to have built-in "generation numbers" soon.
[http://permalink.gmane.org/gmane.comp.version-
control.git/17...](http://permalink.gmane.org/gmane.comp.version-
control.git/177146)

edit: jacknagel points out that they actually didn't go with this after all.
Insted:
[https://github.com/git/git/commit/ffc4b8012d9a4f92ef238ff72c...](https://github.com/git/git/commit/ffc4b8012d9a4f92ef238ff72c0d15e9e1b402ed)

~~~
jrockway
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
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
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".

~~~
stephen
This will give you r/1232:

[https://github.com/stephenh/git-
central/blob/master/server/p...](https://github.com/stephenh/git-
central/blob/master/server/post-receive-commitnumbers)

(It makes a tag-per-commit; I'm not saying that's necessarily a good idea, but
if you _really_ want revision numbers...)

------
srd
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.

~~~
LukeShu
It's referring the the hashes themselves (0001..., 0002..., 0003...), not the
html/css GitHub uses.

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

~~~
davvid
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>

~~~
vog
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>

