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
