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

2024-02-12 Thread Simon Tournier
Hi,

On sam., 03 févr. 2024 at 19:43, Giovanni Biscuolo  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.gg11...@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



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

2024-02-03 Thread Giovanni Biscuolo
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 
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/ph0pr08mb773203ce3206b8defb172b2f94...@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.8GNU Guix 0.8.
v0.7GNU Guix 0.7.
v0.6GNU Guix 0.6.
v0.5GNU Guix 0.5.
v0.4GNU Guix 0.4.
v0.3GNU Guix 0.3.
v0.2GNU Guix 0.2.
v0.1GNU Guix 0.1.
v0.0Guix 0.0, initial announcement.

--8<---cut here---end--->8---

HTH!

Happy hacking, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature