Re: Version numbers for VCS snapshots

[Leo Famulari <leo@famulari.name>]

On Thu, Jan 21, 2016 at 10:05:36PM +0100, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> 
> > On Thu, Jan 21, 2016 at 10:40:41AM +0100, Ricardo Wurmus wrote:
> >> 
> >> Leo Famulari <leo@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