`git describe`

[Rainer Müller]

On 2016-11-28 10:18, René J.V. Bertin wrote:
> Git has a very useful feature when tags are used properly, where each
> commit increases a counter so that the `git describe` command returns
> the current release version plus a patchlevel. I use this in certain
> of my KF5 -devel ports but one can also imagine a MacPorts-devel (or
> -testing or -beta) port. It's also a more convenient way to check for
> new releases after doing a pull (instead of browsing through the list
> of tags).
> 
> I expected to see something along the lines of
> 
> v2.3.5-N-gc75305a
> 
> for the current MacPort-base master/head, but instead I get
> 
> v2.0.0-beta1-1966-gc75305a
> 
> meaning there have been 1966 commits since the v2.0.0-beta1 release
> in some distant past. Yet the v2.3.5 tag exists, evidently.

The latest reachable tag on master is in fact v2.0.0-beta1, so this
output of 'git describe' is correct. All other more recent tags have
been made on the corresponding release-2.x branches.

$ git describe release-2.3
v2.3.5-1-g66c9a86

What you expected would only work with an entirely linear history
without branches.

> This is part of the git magic I never seem to be able to retain, but
> I *think* that in order to get this to work you need to use
> git-release when the tag doesn't exist yet. I know 1 other repository
> maintained by sufficiently knowledgeable devs where apparently this
> doesn't work for some obscure reason so I'm certainly not claiming
> that v2.3.5 wasn't pushed with git-release. Still, it'd be nice to
> have `git describe` work correctly by the next release.

$ git-release
-bash: git-release: command not found
$ git release
git: 'release' is not a git command. See 'git --help'.

No idea what you mean with this. Are you talking about GitHub releases?
That would not change anything.

Rainer