[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Version numbers for VCS snapshots
From: |
Leo Famulari |
Subject: |
Re: Version numbers for VCS snapshots |
Date: |
Sat, 20 Feb 2016 23:35:15 -0500 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Thu, Jan 21, 2016 at 10:05:36PM +0100, Ludovic Courtès wrote:
> Leo Famulari <address@hidden> skribis:
>
> > On Thu, Jan 21, 2016 at 10:40:41AM +0100, Ricardo Wurmus wrote:
> >>
> >> Leo Famulari <address@hidden> 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
- Re: Version numbers for VCS snapshots,
Leo Famulari <=