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

[Simon Tournier]

Hi,

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