[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.