guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Version numbers for VCS snapshots


From: Ludovic Courtès
Subject: Re: Version numbers for VCS snapshots
Date: Tue, 23 Feb 2016 12:53:00 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Christopher Allan Webber <address@hidden> skribis:

> Leo Famulari writes:
>
>> On Sun, Feb 21, 2016 at 12:17:19PM +0300, Alex Kost wrote:
>>> Leo Famulari (2016-02-21 07:35 +0300) wrote:
>>> 
>>> > On Thu, Jan 21, 2016 at 10:05:36PM +0100, Ludovic Courtès wrote:
>>> [...]
>>> >> 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
>>> 
>>> Hm, when I tried "git rev-list --objects --all" I got some ridiculous
>>> number of lines (I pressed C-c C-c after about 78000 lines).  Does this
>>> command really do what you wanted?  (I'm sorry I didn't RTFM well enough
>>> to understand what it does).
>>
>> It lists the objects in the repository, so not just commits. I'm not
>> presenting this as evidence that something is wrong with our repo, just
>> that 7 characters is not enough to unambiguously refer to things in git
>> repos of projects our size. For example, with `git show`.
>>
>> It's more of an informational link than a call to action. Although I am
>> updating all of our uses of git-reference to use the method we agreed
>> upon upthread, before any of those upstream repos grow too large for the
>> identifiers we are currently using.
>
> Yes, short identifiers probably should not be relied upon.

Agreed.  The manual suggests using full-length hashes to identify
commits (info "(guix) Version Numbers").  Commit 561360a (or should I
say 561360a589d2bea0b01b38aa9049b8e69cfad2e7? :-)) adds an example of
this.

It would be nice to have ‘guix lint’ check for show commit IDs in
‘git-reference’ objects.

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]