On Thu, Jan 21, 2016 at 10:05:36PM +0100, Ludovic Courtès wrote: > Leo Famulari <l...@famulari.name> skribis: > > > On Thu, Jan 21, 2016 at 10:40:41AM +0100, Ricardo Wurmus wrote: > >> > >> Leo Famulari <l...@famulari.name> writes: > >> > >> > That sounds good to me. There was some discussion of how much of the > >> > hash to keep here: > >> > http://lists.gnu.org/archive/html/guix-devel/2015-12/msg00136.html > >> > > >> > I like this method that I've seen in some of the packages, because it > >> > keeps the version tidy while preserving the full hash: > >> > > >> > --8<---------------cut here---------------start------------->8--- > >> > (define-public hello > >> > (let ((commit "e8e46123cfe62170a2f7f79db6b471b66ae36947")) > >> > (package > >> > (name "hello") > >> > (version (string-append "2.10-1" (string-take commit 8))) > >> > (source (origin > >> > (method git-fetch) > >> > (uri (git-reference > >> > (url "git://git.sv.gnu.org/hello.git") > >> > (commit commit))) > >> > (sha256 > >> > [...] > >> > --8<---------------cut here---------------end--------------->8--- > >> > >> I like this approach (though I’ve been taking 9 characters of the commit > >> ;)). > > > > I like 10 but I wanted to match your example upthread ;) > > I prefer 7! This is how Git usually truncates SHA1s, so it can’t be wrong.
I stumbled across this email earlier, which reminded me of this discussion about hash lengths: https://lkml.org/lkml/2010/10/28/287 There are currently 13 7-character hash collisions in Guix's git repo: $ git rev-list --objects --all | cut -c1-7 | sort | uniq -dc 2 0d2b24c 2 11e0632 2 1f3ab8d 2 229bd6c 2 7c4a7b7 2 9ff8b63 2 aa27b56 2 c10c562 2 d96cdce 2 dab4329 2 dc27d1c 2 ea119a2 2 f56cc27
