GNU bug report logs - #63775
git describe on current master says: v1.3.0-38775-g6192acf8b7

Previous Next

Package: guix;

Reported by: Janneke Nieuwenhuizen <janneke <at> gnu.org>

Date: Sun, 28 May 2023 15:17:02 UTC

Severity: normal

Done: Giovanni Biscuolo <g <at> xelera.eu>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63775 in the body.
You can then email your comments to 63775 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#63775; Package guix. (Sun, 28 May 2023 15:17:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Janneke Nieuwenhuizen <janneke <at> gnu.org>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Sun, 28 May 2023 15:17:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Janneke Nieuwenhuizen <janneke <at> gnu.org>
To: bug-guix <at> gnu.org
Subject: git describe on current master says: v1.3.0-38775-g6192acf8b7
Date: Sun, 28 May 2023 17:16:08 +0200
Hi!

Subject says it all:

--8<---------------cut here---------------start------------->8---
17:12:25 janneke <at> drakenpad:~/src/guix/master [env]
$ git fetch origin
17:12:56 janneke <at> drakenpad:~/src/guix/master [env]
$ git fetch origin --tags
17:13:04 janneke <at> drakenpad:~/src/guix/master [env]
$ git reset --hard origin/master
HEAD is now at 6192acf8b7 gnu: telegram-desktop: Update to 4.8.1
17:13:09 janneke <at> drakenpad:~/src/guix/master [env]
$ git describe
v1.3.0-38775-g6192acf8b7
--8<---------------cut here---------------end--------------->8---

(There was a question on IRC by cassio: "How do I upgrade to 1.4",
 but I don't see it in the channel logs yet).

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke <at> gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com




Information forwarded to bug-guix <at> gnu.org:
bug#63775; Package guix. (Tue, 30 May 2023 16:23:02 GMT) Full text and rfc822 format available.

Message #8 received at 63775 <at> debbugs.gnu.org (full text, mbox):

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Janneke Nieuwenhuizen <janneke <at> gnu.org>, 63775 <at> debbugs.gnu.org
Subject: Re: bug#63775: git describe on current master says:
 v1.3.0-38775-g6192acf8b7
Date: Tue, 30 May 2023 17:25:01 +0200
Hi,

On dim., 28 mai 2023 at 17:16, Janneke Nieuwenhuizen <janneke <at> gnu.org> wrote:

> --8<---------------cut here---------------start------------->8---
> 17:12:25 janneke <at> drakenpad:~/src/guix/master [env]
> $ git fetch origin
> 17:12:56 janneke <at> drakenpad:~/src/guix/master [env]
> $ git fetch origin --tags
> 17:13:04 janneke <at> drakenpad:~/src/guix/master [env]
> $ git reset --hard origin/master
> HEAD is now at 6192acf8b7 gnu: telegram-desktop: Update to 4.8.1
> 17:13:09 janneke <at> drakenpad:~/src/guix/master [env]
> $ git describe
> v1.3.0-38775-g6192acf8b7
> --8<---------------cut here---------------end--------------->8---

Oh, that’s weird!

--8<---------------cut here---------------start------------->8---
$ git describe --debug
describe HEAD
No exact match on refs or tags, searching to describe
 annotated      38817 v1.3.0
 annotated      38831 v1.3.0rc2
 annotated      38870 v1.3.0rc1
 annotated      55660 base-for-issue-62196
 annotated      55806 v1.2.0
 annotated      55814 v1.2.0rc2
 annotated      55837 v1.2.0rc1
 annotated      55985 v1.4.0
 annotated      55998 v1.4.0rc2
 annotated      56031 v1.4.0rc1
traversed 56356 commits
more than 10 tags found; listed 10 most recent
gave up search at d62c9b2671be55ae0305bebfda17b595f33797f2
v1.3.0-38817-g76b7bc5392

$ git rev-list --count v1.3.0..HEAD
38817
--8<---------------cut here---------------end--------------->8---

The manual reads,

        SEARCH STRATEGY

        [...]

             If an exact match was not found, git describe will walk back
             through the commit history to locate an ancestor commit
             which has been tagged. The ancestor’s tag will be output
             along with an abbreviation of the input commit-ish’s
             SHA-1. If --first-parent was specified then the walk will
             only consider the first parent of each commit.

             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.

And then,

--8<---------------cut here---------------start------------->8---
$ git rev-list --count v1.4.0..HEAD
9980
--8<---------------cut here---------------end--------------->8---

Hum, why does “git describe” count 55985?  Well, it’s weird, for
instance, using my repository, the DAG looks like:

--8<---------------cut here---------------start------------->8---
$ git --no-pager log --all --graph --simplify-by-decoration --format="%h %d"
* 76b7bc5392  (HEAD -> master)
* 2b1b0a580d  (origin/master, origin/HEAD)
| * ecb19e3353  (origin/tex-team-next)
| * bb07562a89  (origin/tex-team)
|/  

[...]

* 45fd01ac5d  (tag: base-for-issue-62196)

[...]

| * d8abcffda5  (origin/wip-guile-ssh-0.16)
|/  
| * e81a75a7b2  (origin/wip-r)
|/  
* 989a3916dc  (origin/version-1.4.0)
* 8e2f32cee9  (tag: v1.4.0)  
* 7866294e32  (tag: v1.4.0rc2)
* 020184fd39  (tag: v1.4.0rc1)
| * 7966084069  (origin/wip-aarch64-bootstrap)

[...]

| * 8d84a9ee71  (origin/version-1.2.0)
| | * aa34d4d28d  (origin/version-1.3.0)
| |/  
|/|   
| | * 592101268f  (origin/wip-ppc)
| |/  
|/|   
* | a0178d34f5  (tag: v1.3.0)
* | 7a65beff0f  (tag: v1.3.0rc2)
* | 0d353b06ec  (tag: v1.3.0rc1)
|/  
| * fafad6b17c  (origin/wip-node-importer)
--8<---------------cut here---------------end--------------->8---

Therefore, I would be expecting that the tag ’base-for-issue-62196’
would be the output of “git describe”.


> (There was a question on IRC by cassio: "How do I upgrade to 1.4",
>  but I don't see it in the channel logs yet).

Well, about upgrading to 1.4, it depends from which Guix revision. :-)

Something like,

    guix pull --commit=8e2f32cee982d42a79e53fc1e9aa7b8ff0514714

should do the job.  And if not, the answer will depend on the current
Guix revision which requires an update.


Cheers,
simon




Information forwarded to bug-guix <at> gnu.org:
bug#63775; Package guix. (Thu, 08 Jun 2023 14:00:02 GMT) Full text and rfc822 format available.

Message #11 received at 63775 <at> debbugs.gnu.org (full text, mbox):

From: Giovanni Biscuolo <g <at> xelera.eu>
To: Simon Tournier <zimon.toutoune <at> gmail.com>,
 Janneke Nieuwenhuizen <janneke <at> gnu.org>, 63775 <at> debbugs.gnu.org
Subject: Re: bug#63775: git describe on current master says:
 v1.3.0-38775-g6192acf8b7
Date: Thu, 08 Jun 2023 15:58:50 +0200
[Message part 1 (text/plain, inline)]
Hi,

thank you Janneke for this report, I thought I had some problem with my
working dir

magit tells me I'm on "Tag:      v1.3.0 (39040)"

Simon Tournier <zimon.toutoune <at> gmail.com> writes:

[...]

> Oh, that’s weird!
>
> --8<---------------cut here---------------start------------->8---
> $ git describe --debug
> describe HEAD
> No exact match on refs or tags, searching to describe
>  annotated      38817 v1.3.0
>  annotated      38831 v1.3.0rc2
>  annotated      38870 v1.3.0rc1
>  annotated      55660 base-for-issue-62196
>  annotated      55806 v1.2.0
>  annotated      55814 v1.2.0rc2
>  annotated      55837 v1.2.0rc1
>  annotated      55985 v1.4.0
>  annotated      55998 v1.4.0rc2
>  annotated      56031 v1.4.0rc1
> traversed 56356 commits
> more than 10 tags found; listed 10 most recent
> gave up search at d62c9b2671be55ae0305bebfda17b595f33797f2
> v1.3.0-38817-g76b7bc5392
>
> $ git rev-list --count v1.3.0..HEAD
> 38817
> --8<---------------cut here---------------end--------------->8---

I have the very same (updated) results:

[...]

--8<---------------cut here---------------start------------->8---

  0 LC_ALL=C git describe --debug
describe HEAD
No exact match on refs or tags, searching to describe
 annotated      39040 v1.3.0
 annotated      39054 v1.3.0rc2
 annotated      39093 v1.3.0rc1
 annotated      55883 base-for-issue-62196
 annotated      56029 v1.2.0
 annotated      56037 v1.2.0rc2
 annotated      56060 v1.2.0rc1
 annotated      56208 v1.4.0
 annotated      56221 v1.4.0rc2
 annotated      56254 v1.4.0rc1
traversed 56579 commits
more than 10 tags found; listed 10 most recent
gave up search at d62c9b2671be55ae0305bebfda17b595f33797f2
v1.3.0-39040-g76b7c50645

--8<---------------cut here---------------end--------------->8---
(output from magit-process)

[...]

I'm not so expert in git, still trying to understand how to debug this
strange behaviuor

Happy hacking! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#63775; Package guix. (Wed, 31 Jan 2024 20:10:02 GMT) Full text and rfc822 format available.

Message #14 received at 63775 <at> debbugs.gnu.org (full text, mbox):

From: Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
To: 63775 <at> debbugs.gnu.org
Subject: git describe on current master says: v1.3.0-38775-g6192acf8b7
Date: Wed, 31 Jan 2024 21:08:45 +0100
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.

So in the end the package looks like `guix-1.3.0+git*.rpm` which is a
problem, because the normal Guix package is already `guix-1.4.0*.rpm`.
RPM then thinks the package is older...

~Jonathan




Reply sent to Giovanni Biscuolo <g <at> xelera.eu>:
You have taken responsibility. (Sat, 03 Feb 2024 18:44:02 GMT) Full text and rfc822 format available.

Notification sent to Janneke Nieuwenhuizen <janneke <at> gnu.org>:
bug acknowledged by developer. (Sat, 03 Feb 2024 18:44:02 GMT) Full text and rfc822 format available.

Message #19 received at 63775-close <at> debbugs.gnu.org (full text, mbox):

From: Giovanni Biscuolo <g <at> xelera.eu>
To: Jonathan Brielmaier <jonathan.brielmaier <at> web.de>,
 63775-close <at> debbugs.gnu.org
Cc: guix-devel <at> gnu.org, Simon Tournier <zimon.toutoune <at> gmail.com>
Subject: Re: bug#63775: git describe on current master says:
 v1.3.0-38775-g6192acf8b7
Date: Sat, 03 Feb 2024 19:43:14 +0100
[Message part 1 (text/plain, inline)]
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 <at> 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 <at> farprobe/

Another user also reported the issue and a reproducer:
https://public-inbox.org/git/PH0PR08MB773203CE3206B8DEFB172B2F94839 <at> 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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#63775; Package guix. (Mon, 12 Feb 2024 13:00:03 GMT) Full text and rfc822 format available.

Message #22 received at 63775-close <at> debbugs.gnu.org (full text, mbox):

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Giovanni Biscuolo <g <at> xelera.eu>, Jonathan Brielmaier
 <jonathan.brielmaier <at> web.de>, 63775-close <at> debbugs.gnu.org
Cc: guix-devel <at> gnu.org
Subject: Re: bug#63775: git describe on current master says:
 v1.3.0-38775-g6192acf8b7
Date: Mon, 12 Feb 2024 10:17:17 +0100
Hi,

On sam., 03 févr. 2024 at 19:43, Giovanni Biscuolo <g <at> xelera.eu> wrote:

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

Here the explanation of the bug of “git describe”:

    https://lore.kernel.org/git/20191008123156.GG11529 <at> szeder.dev/
    
      $ git describe d1a251a1fa
      v2.23.0-135-gd1a251a1fa
      $ git log --oneline v2.23.0..d1a251a1fa | wc -l
      59

    Uh-oh, 59 != 135.

    This is happening because:

      - Git is too fast ;) and the committer date has a one second
        granularity, so scripts can easily create subsequent commits with
        the same committer date.  Case in point are the two subsequent
        merge commits f3c19f85c5 and 4a3ed2bec6 at the bottom of this
        simplified history snippet (kind of a hand-edited 'git log --graph
        --format="%h %cd %s"'):

        *   d1a251a1fa 2019-09-09 12:26:36 -0700 Merge branch 'en/checkout-mismerge-fix'
        |\
        * | ... a big chunk of history simplified away ...
        | * acb7da05ac 2019-08-16 09:58:00 -0700 checkout: remove duplicate code
        * | a5e4be2f68 2019-04-25 16:41:15 +0900 Merge branch 'ab/commit-graph-fixes'
        * | f3c19f85c5 2019-04-25 16:41:14 +0900 Merge branch 'ab/gc-reflog'
        |/
        *   4a3ed2bec6 2019-04-25 16:41:14 +0900 Merge branch 'nd/checkout-m'

      - 'git describe' implements its own history traversal: it iterates
        over all parents of a commit, adds any yet unseen parents to a
        commit list ordered by date, and then continues with the first,
        i.e. most recent commit from that list.  While doing so it uses
        several bits in 'commit->object.flags' to track reachability
        information from several candidate tags at once, and copies these
        flags from each commit to its parents; this is important to
        compute the correct number of additional commits.  Another
        important thing is the implementation detail that
        commit_list_insert_by_date() inserts a new commit after all other
        commits with the same date that are already in the list.


Thanks Giovanni for pointing this out.

Cheers,
simon




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 12 Mar 2024 11:24:22 GMT) Full text and rfc822 format available.

This bug report was last modified 45 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.