git describe on current master says: v1.3.0-38775-g6192acf8b7

  • Done
  • quality assurance status badge
Details
4 participants
  • Giovanni Biscuolo
  • Janneke Nieuwenhuizen
  • Jonathan Brielmaier
  • Simon Tournier
Owner
unassigned
Submitted by
Janneke Nieuwenhuizen
Severity
normal
J
J
Janneke Nieuwenhuizen wrote on 28 May 2023 17:16
(address . bug-guix@gnu.org)
87pm6k5vwn.fsf@gnu.org
Hi!

Subject says it all:

Toggle snippet (12 lines)
17:12:25 janneke@drakenpad:~/src/guix/master [env]
$ git fetch origin
17:12:56 janneke@drakenpad:~/src/guix/master [env]
$ git fetch origin --tags
17:13:04 janneke@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@drakenpad:~/src/guix/master [env]
$ git describe
v1.3.0-38775-g6192acf8b7

(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@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
S
S
Simon Tournier wrote on 30 May 2023 17:25
87jzwpsuya.fsf@gmail.com
Hi,

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

Toggle quote (13 lines)
> --8<---------------cut here---------------start------------->8---
> 17:12:25 janneke@drakenpad:~/src/guix/master [env]
> $ git fetch origin
> 17:12:56 janneke@drakenpad:~/src/guix/master [env]
> $ git fetch origin --tags
> 17:13:04 janneke@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@drakenpad:~/src/guix/master [env]
> $ git describe
> v1.3.0-38775-g6192acf8b7
> --8<---------------cut here---------------end--------------->8---

Oh, that’s weird!

Toggle snippet (22 lines)
$ 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

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,

Toggle snippet (4 lines)
$ git rev-list --count v1.4.0..HEAD
9980

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

Toggle snippet (39 lines)
$ 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)

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


Toggle quote (3 lines)
> (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
G
G
Giovanni Biscuolo wrote on 8 Jun 2023 15:58
878rcujbs5.fsf@xelera.eu
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@gmail.com> writes:

[...]

Toggle quote (25 lines)
> 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:

[...]

Toggle snippet (20 lines)
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

(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
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmSB3poMHGdAeGVsZXJh
LmV1AAoJENN9DqfOzDkS41kP+gPW1zZ6/OtsEafiNls2zdK7Qtk2Lbykvre/6GPv
oGnRKkd1GhUJzuVxTI4nkS5a6w7BEMiRQuB2XwefiqEQVeFslDV+F/MlSQjUDkir
aRPSWaCp9hBh5T423P8MjE14KBAryVLc8gcHlTByxiXal5As+czh0Wccr6dk7cjt
gPDgBhIoYScJHc7dxM601mxWhJdaHn3o1vZ+klMRdiKIqFuuma0VbenMT3OH6wNE
JciDTCSHx6PM/pOqQGXILjmQNwAu+T1cRN+yUgTQBhq4oG/R6YZeVEUpDm6S2S99
nE4RmlJ9+38TBNrJbW1ST/SvxwW8DiNWVGU5T14eOXUO0CYvGpYQMdS0GvXiZNXP
XKkEn0L83HrAahsPVcimDypwKgkzpjYtgFl51AsnjXzjJ+6maCl+Nqw6OhBbacj+
D7vUjYnQKW94TvzoHZGLHgIIOcW/T/KjKALgE5hcCFfGH7C4PvQr/T+0PVWAeV9X
vReSO6BsHRFhY06TcyeHLDqCeXtjQBTbl8aRccEOY2mwi14vAYzDyxVziTKW5svD
xHdMXtoGPdDwlgO9xLraMTQ0jHfGKhXfN6ae+t0cZrPel2+ghVWHJOLOascWvE5t
7hgw9W4EBrN/+tQM9DvPlx2Ug/3nkyNZnUNU7QdkpipJbKbWerQTto2gSxoakHy0
YtuF
=9yZl
-----END PGP SIGNATURE-----

J
J
Jonathan Brielmaier wrote on 31 Jan 21:08 +0100
git describe on current master says: v1.3.0-38775-g6192acf8b7
(address . 63775@debbugs.gnu.org)
dc1000b2-6c9f-4a84-ab59-4bab8fec8ef2@web.de
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
G
G
Giovanni Biscuolo wrote on 3 Feb 19:43 +0100
87le81bd8d.fsf@xelera.eu
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:

Toggle quote (5 lines)
> 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

Toggle snippet (9 lines)
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.


The upstream bug report (and a reproducer) is this one:
«Subject: [BUG] `git describe` doesn't traverse the graph in topological
order»

Another user also reported the issue and a reproducer:

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:

Toggle snippet (6 lines)
$ git describe $(git rev-list --tags --max-count=1)
base-for-issue-62196


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:

Toggle snippet (6 lines)
$ git describe $(git rev-list --tags="v[0-9]*" --max-count=1)
v1.4.0


To browse all the tags there is the "git tag" command, for example to
have the list and description of every Guix released version:

Toggle snippet (39 lines)
$ 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.


HTH!

Happy hacking, Gio'

--
Giovanni Biscuolo

Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmW+iUMMHGdAeGVsZXJh
LmV1AAoJENN9DqfOzDkSFaQP/iYotAPeTDFBu+TZLh0vcE0SpIACEL5XFQj3tgDr
eYx5b7ODJaESeqSLcJqbaQbe2/E95XicfCyC5tV5yDqpKqJ0qqBcG8EHqTU+Wp9x
GwE8QjNsfgZKHSeFxS23Y1tGyYEU/uv8tr2o9KMLEI2jEcTDWBtPmjzhknKODhxl
Cx9EfJ83Twz4h70NurG5iHAYUkYIyIRMrwHwx5EVv91WnRN5mkIyC0WJfyQxhbXo
KNeZlH64YKELeWkjVsTnKDVapBQsgHJE2UBqZyiDXZDFoxhJo+BTRXHXWsRO4xao
JbGpe/p77p2FxuuOjxk+1jhmwAKWASXkRTXIRdqx7odpx6tjz72KJqdIeSLxtNrR
GOWhNXy2no6vmFkqK5diybGIR4Al9pbgNiS3SfNdXLFUodqhbFbO+4YtfFznhmQW
1vOOzofv2xGfXt0rnu9+0GaSgd0NfjJpbE/BsWYX9ILAQdXwBPkYLFVVBalKdrLk
ontodcUcnbfii0kra+Ey2oygCE0aqJyReO0jEcl4DlYAEM5uW67Jfn9RN7A/ajE6
I5IDapq5RZkl4TYv0jAGrKnQrdqHRtjpZfC0YQJqORTZbqlvMx52JwVtifEPoFpJ
JKEyrkSXdsoKg4OKTXfStGkZ+jP9Ol8USHgSXNxBgXgL5dymQsXlClvLCrcK/r5w
YSsD
=tnb7
-----END PGP SIGNATURE-----

S
S
Simon Tournier wrote on 12 Feb 10:17 +0100
(address . guix-devel@gnu.org)
871q9i2g9u.fsf@gmail.com
Hi,

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

Toggle quote (3 lines)
> 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”:

$ 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
?
Your comment

This issue is archived.

To comment on this conversation send an email to 63775@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 63775
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch