lmi
[Top][All Lists]
Advanced

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

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


From: Greg Chicares
Subject: Re: [lmi] [lmi-commits] master 53e1802 4/8: Use a gainlier name for source directory
Date: Sun, 21 May 2017 17:03:06 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 2017-05-21 16:14, Vadim Zeitlin wrote:
> On Thu, 18 May 2017 22:45:45 -0400 (EDT) Greg Chicares <address@hidden> wrote:
> 
> GC> branch: master
> GC> commit 53e1802120a17c69a822907c9806d57c2d5774e7
[...]
> GC> -  wx_version        := $(wx_commit_sha)
> GC> +# Use a string distinct from any official wxwidgets.org release name
> GC> +# and from any such string previously used in this makefile.
> GC> +  wx_version        := 3.1.0-p1
> 
>  FWIW I think the string returned by "git describe", e.g. something like
> v3.1.0-1337-g33b0a70 currently for me (I swear the leetspeak is wholly
> incidental), is more useful as it's still relatively readable, but also
> uniquely identifies the version being used.

Interesting--I had never heard of such a command. I looked here:
  
https://gitfu.wordpress.com/2008/05/25/git-describe-great-another-way-to-refer-to-commits/
| Wouldn’t it be great if git had a revision number that always went up so that
| you could look at two of them and figure out which one was later than the 
other?
and that sounded interesting, but:

$git describe
fatal: No names found, cannot describe anything.

I don't have any tags. I used them in svn, but I'm not sure that's an
svn feature that I really miss.

Of course, I can do this:

$git describe --always
b75c427

but that just gives me an abbreviated commit. I didn't want to use that because
I fear it will fail if someday we get a seven-character collision.

>  In fact, I think it would be nice(r) to use this string as part of the
> vendor string too.

Yes, that's icky, too, and ought to be improved. I changed one of them because
I needed to add a file that would otherwise have been named
  wx-41045df7ea5f93e4c07c1bd846d7127a372705bd.patch
but that was just a temporary expedient. I'm willing to consider a general
improvement in these names. But, returning to the example above, why would the
second string be more helpful than the first?
  3.1.0-p1             [first]
  v3.1.0-1337-g33b0a70 [second]
The first means it's wx-3.1.0 with lmi patch 1. Does the second mean...
  wx-3.1.0
  1337 commits after...
  g33b0a70 ...this sha1sum?
I can see how that could be useful if you build wx frequently and retain
various versions of it, but I build wx rarely and erase old versions. If I
want to know what the sha1sum is, I can look that up in the lmi makefile.




reply via email to

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