`git describe`

[René J.V. Bertin]

On Monday November 28 2016 10:45:39 Rainer Müller wrote:

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

That's not my experience with the KDE repositories I'm working with. They too have repos where development is done on release branches and then merged into the master branch regularly, which keeps the master branch what one would expect it to be. That is, a reflection of what the next release will look like, even if/when that will be a major release.
Check the konsole repo for instance (git://anongit.kde.org/konsole). It's not perfect, but master describes as v16.08.2-83-g378518e (ought to be 16.08.3) while the most recent released KDE4 version describes as v4.14.3 .

I presume that means they merge the development branch into master before creating the 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.

Possibly: 

%> port provides /opt/local/bin/git-release
/opt/local/bin/git-release is provided by: git-extras

It does change something. Don't ask me the details but the 1 or 2 times that I've tried to make a release which behaves correctly w.r.t. git-describe I succeeded with that command, not by creating the tag manually. IIRC it had something to do with getting the tag pushed to the remote, which doesn't (necessarily) happen automatically when you create a tag and then push.

R.
R.