`git describe`

[René J.V. Bertin]

On Monday November 28 2016 20:16:17 Rainer Müller wrote:

>No, not at all. What you might see there are not the same commit
>objects, as the changes were cherry-picked from master to release-2.3.

I'll take your word for it, it's much easier to compare commit messages than random commit hashes.

>As you discovered yourself now, 'port version' of master identifies
>itself as 2.3.99 at the moment.

Yes, and if you look at the history of the script in config that sets that version, it apparently has been fixed at 2.3.99 for about 2 years now.

>The only way I would see to make them reachable is to merge release-X.Y
>back into master, while ignoring all actual code changes and conflicts.
>This would only have the purpose of making the tag reachable.

If master contains in fact a parallel version it wouldn't make much sense to let it follow the exact versions of the releases. It could have tags that are somehow related so that at least one can see in a glance which is the latest release version that doesn't have features not in a given master version (if release branches are never ahead of master in terms of features).
I don't really have any brilliant idea what such a master versioning scheme could look like. Maybe prepend "m.", where m.2.3.6 would be the tag in master made immediately after having tagged the 2.3.6 release in release-2.3?

>You did not start this thread with the intention of adding a commit hash
>to 'port version'. You put out a question about 'git describe', but
>apparently you did not even look up or understood what it does or how it
>works. 

I didn't investigate exactly how it works, but I do know it's based on annotaged tags, and of course when I said that it'd be nice if in the future `git describe` could return something more appropriate than the current string I assumed that I didn't have to explain how to achieve that.
I'm not sure how `port version` relates to this and why it would contain a commit hash. If I take that literally it's even the opposite of what I have in mind: commit hashes are random so you can't use them in a monotonically increasing version number.

My error: `git describe` returns <tag>-<counter>-g<hash> when it can find a supported tag; it's the counter that can be used in a version number.

>Please excuse me if I got snarky after doing this stuff, which – in my
>opinion – you could have worked out yourself by reading the appropriate
>documentation and experimenting.

What good would it do me to figure out something that I find suitable if I cannot apply it to macports-base?

>To get back to MacPorts base, the relevant code that sets/extracts the
>version information for 'port version' is in configure.ac:

See above: the invoked shell script hasn't been changed for over 2 years. 

R.