From: Giovanni Biscuolo <g@xelera.eu>
To: Jonathan Brielmaier <jonathan.brielmaier@web.de>,
63775-close@debbugs.gnu.org
Cc: guix-devel@gnu.org, Simon Tournier <zimon.toutoune@gmail.com>
Subject: bug#63775: git describe on current master says: v1.3.0-38775-g6192acf8b7
Date: Sat, 03 Feb 2024 19:43:14 +0100 [thread overview]
Message-ID: <87le81bd8d.fsf@xelera.eu> (raw)
In-Reply-To: <dc1000b2-6c9f-4a84-ab59-4bab8fec8ef2@web.de>
[-- Attachment #1: Type: text/plain, Size: 4262 bytes --]
Hi Jonathan,
I'm CC'ing guix-devel because I suspect many users who cloned/updated
the Guix repo are having the same results... and concerns.
This is a git bug, not an issue with our repo, and for this reason (I
hope) I'm closing this bug; please see below.
Jonathan Brielmaier via Bug reports for GNU Guix <bug-guix@gnu.org>
writes:
> Hm, I'm hitting this bug while trying to work on the openSUSE package.
> They offer a way to build RPM packages from the most recent master
> commit, but it's get the wrong version (1.3.0 instead of 1.4.0) due to
> this `git describe` result.
As pointed out by Simon last June the result of "git describe" is not
what users should get given the "Search strategy" documented in the
command manual: https://git-scm.com/docs/git-describe#_search_strategy:
--8<---------------cut here---------------start------------->8---
If multiple tags were found during the walk then the tag which has the
fewest commits different from the input commit-ish will be selected and
output. Here fewest commits different is defined as the number of
commits which would be shown by git log tag..input will be the smallest
number of commits possible.
--8<---------------cut here---------------end--------------->8---
The upstream bug report (and a reproducer) is this one:
«Subject: [BUG] `git describe` doesn't traverse the graph in topological
order»
https://lore.kernel.org/git/ZNffWAgldUZdpQcr@farprobe/
Another user also reported the issue and a reproducer:
https://public-inbox.org/git/PH0PR08MB773203CE3206B8DEFB172B2F94839@PH0PR08MB7732.namprd08.prod.outlook.com/
The "executive summary" is that "git describe" gets the count of "fewest
commits different from the input commit-ish" wrong (see anso previous
messages in this thread for details).
Anyway, even if this bug was solved, I'd warmly suggest NOT to base the
check for the latest stable Guix commit (usually tagged as v[0-9]*) on
the result of "git describe".
Today, if "guix describe" had no bugs, the correct result would be:
"base-for-issue-62196"... AFAIU :-)
This is a reproducer:
--8<---------------cut here---------------start------------->8---
$ git describe $(git rev-list --tags --max-count=1)
base-for-issue-62196
--8<---------------cut here---------------end--------------->8---
To get the value corresponding to the latest tagged version, we should
testrict the list of tags to the ones matching the "v[0-9]*" regexp:
--8<---------------cut here---------------start------------->8---
$ git describe $(git rev-list --tags="v[0-9]*" --max-count=1)
v1.4.0
--8<---------------cut here---------------end--------------->8---
To browse all the tags there is the "git tag" command, for example to
have the list and description of every Guix released version:
--8<---------------cut here---------------start------------->8---
$ git tag -l "v[0-9]*" --sort=-creatordate -n
v1.4.0 GNU Guix 1.4.0.
v1.4.0rc2 GNU Guix 1.4.0rc2.
v1.4.0rc1 GNU Guix 1.4.0rc1.
v1.3.0 GNU Guix 1.3.0.
v1.3.0rc2 GNU Guix 1.3.0rc2.
v1.3.0rc1 GNU Guix 1.3.0rc1.
v1.2.0 GNU Guix 1.2.0.
v1.2.0rc2 GNU Guix 1.2.0rc2.
v1.2.0rc1 GNU Guix 1.2.0rc1.
v1.1.0 GNU Guix 1.1.0.
v1.1.0rc2 GNU Guix 1.1.0rc2.
v1.1.0rc1 GNU Guix 1.1.0rc1.
v1.0.1 GNU Guix 1.0.1.
v1.0.0 GNU Guix 1.0.0.
v0.16.0 GNU Guix 0.16.0.
v0.15.0 GNU Guix 0.15.0.
v0.14.0 GNU Guix 0.14.0.
v0.13.0 GNU Guix 0.13.0.
v0.12.0 GNU Guix 0.12.0
v0.11.0 GNU Guix 0.11.0.
v0.10.0 GNU Guix 0.10.0.
v0.9.0 GNU Guix 0.9.0.
v0.8.3 GNU Guix 0.8.3.
v0.8.2 GNU Guix 0.8.2.
v0.8.1 GNU Guix 0.8.1.
v0.8 GNU Guix 0.8.
v0.7 GNU Guix 0.7.
v0.6 GNU Guix 0.6.
v0.5 GNU Guix 0.5.
v0.4 GNU Guix 0.4.
v0.3 GNU Guix 0.3.
v0.2 GNU Guix 0.2.
v0.1 GNU Guix 0.1.
v0.0 Guix 0.0, initial announcement.
--8<---------------cut here---------------end--------------->8---
HTH!
Happy hacking, Gio'
--
Giovanni Biscuolo
Xelera IT Infrastructures
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]
prev parent reply other threads:[~2024-02-03 18:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-28 15:16 bug#63775: git describe on current master says: v1.3.0-38775-g6192acf8b7 Janneke Nieuwenhuizen
2023-05-30 15:25 ` Simon Tournier
2023-06-08 13:58 ` Giovanni Biscuolo
2024-01-31 20:08 ` Jonathan Brielmaier via Bug reports for GNU Guix
2024-02-03 18:43 ` Giovanni Biscuolo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87le81bd8d.fsf@xelera.eu \
--to=g@xelera.eu \
--cc=63775-close@debbugs.gnu.org \
--cc=guix-devel@gnu.org \
--cc=jonathan.brielmaier@web.de \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).