How to show git commit using number of commits since a tag

Question

With git describe you can get the number of commits since the last tag. If you only had the tag and the number of commits what is the best way to show the commit t

Answer 1

What you're asking for is impossible in the general case. The number of commits alone can't tell you anything if there are any merges in your history.

For example, given the following repo structure:

a - b - c - d - h
  \           /
    e - f - g

With a tag put on a, the outputs of git describe d and git describe g are identical save for the SHA1:

> git describe d
tag-3-ge8dca33
> git describe g
tag-3-g4fecc2e

That said, if you don't have a bunch of parallel branches going on at once, then you may be able to resolve a given commit number back to a single commit, but if you have even a single active side branch at the time of your tag then this may not work.

If you need reliable release numbers, you should stick to explicit tags.

Answer 2

what is the best way to find all commits X such that if HEAD was pointing to X git describe would return v1.5-39-*****

is still the wrong question. The right question is

how to find all commits X such that if HEAD was pointing to X an ordinary git describe could ever have returned v1.5-39-*****

and it's not all that easy to answer that. Still, absent enemy action this procedure will list the right commit maybe among some other possibilities:

ancestor=v1.5 n=39
git rev-list --all --reverse --topo-order --parents --ancestry-path ^$ancestor \
| awk ' function minmore(       i) {
                for ( i=2; i <= NF; ++i )
                        if ( gen[$i] > gen[$1] ) 
                                gen[$1]=gen[$i]
                return ++gen[$1]
        }
        minmore()<=n {
                print "[[ $(git rev-list --count "ancestor".."$1") == "n" ]] &&"
                print "         git describe --match="ancestor" "$1 }
      ' ancestor=$ancestor n=$n \
# | sh    # lose the first `#` here to actually run the generated checks

The reason for the uncertainty and complexity is that git describe is just trying to get a reasonable base, so (see its docs) it'll pick the most recent of the closest current tags it can see, and count how many additional commits there are in the described history, and generate a moniker that way. For examples, new tags can change its preferred base such that a bare git describe would no longer generate that moniker; and while SHA's are immutable, references can be rewritten.