multiple lightweight tag on the same commit

[weimingzha0]

When multiple lightweight tags are applied to the same commit, it chooses the first one. Usually, we prefer to return the "latest" tag (largest version number)

To reproduce:

git tag 1.1.0
git tag 1.2.0
git-semver

it returns 1.1.0, but 1.2.0 is preferred

[Nuxij]

Your fix doesn't seem to work for the "dev" target.

I have an issue where I have two tags on the same commit

4.1.0-dev.3
4.1.0-dev.4

For some reason, git-semver thinks that -dev.3 is the correct name, despite -dev.4 being both a higher number, and created later in time.

Am I stupid to want this? I don't want to have to keep adding blank commits to get a new tag out

[weimingzha0]

You're right. Need to handle dev number.

[weimingzha0]

wait..
how do you end up with two "dev" tags on the same commit? dev numbers are the number of commits since the latest release version.

[Nuxij]

Sorry was AFK, missed your message. We have since reverted to using the autogenerated -dev numbers to avoid this. But how we did it was just manually, re-tagging a commit to keep releases uniform even if a certain project hasn't changed.

I think the problem would still exist if I was to do anything else in that extra section, perhaps 1.1.0-anything.1 and 1.1.0-anything.2

[weimingzha0]

I updated the patch to compare "meta" field.
However, note that, it compares alphabetically. (e.g. dev.1 < dev.2, but dev.20 < dev.3) because the "meta" field could have arbitrary string.

[Nuxij]

That works for me; allows a predictable series of -alpha, -bravo, -charlie, etc

[sergeevabc]

Is it completed?