Re: [lmi] [lmi-commits] master 53e1802 4/8: Use a gainlier name for source directory

[Vadim Zeitlin]

On Sun, 21 May 2017 19:13:58 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-05-21 17:13, Vadim Zeitlin wrote:
GC> > On Sun, 21 May 2017 17:03:06 +0000 Greg Chicares <address@hidden> wrote:
...snip...
GC> > GC> The first means it's wx-3.1.0 with lmi patch 1. Does the second 
mean...
GC> > GC>   wx-3.1.0
GC> > GC>   1337 commits after...
GC> > GC>   g33b0a70 ...this sha1sum?
GC> > 
GC> >  Yes, exactly ("g" is not part of SHA-1 though).
GC> 
GC> I have to ask--what does "g" mean, then? Does it stand for something,
GC> like the "g" in "debuG"? Or is it just the first alphabetic character
GC> that is not a hex "digit"?

 I admit I have never bothered checking if this was really the case, but
now I did and, indeed, https://git-scm.com/docs/git-describe confirms my
assumption that "g" here stands for "git":

        The hash suffix is "-g" + 7-char abbreviation for the tip commit of
        parent <...>. The "g" prefix stands for "git" and is used to allow
        describing the version of a software depending on the SCM the
        software is managed with. This is useful in an environment where
        people may use different SCMs.

GC> > It is also automatically unique, so different DLLs will never have
GC> > the same name.
GC> 
GC> Is uniqueness guaranteed absolutely, or probabilistically?

 Absolutely in case of linear history because the number of commits since
the (unique) tag name is already enough to uniquely identify the commit,
the SHA-1 is just an extra convenience. I guess that when branches are
used, it would be only probabilistic as a collision of the first 7
characters of a SHA-1 is, of course, possible, and it is also possible that
it happens for 2 commits on different branches which have exactly the same
number of parent commits since the latest tag. Needless to say, this seems
pretty unlikely.

 Regards,
VZ