Selects wrong version if multiple lightweight tags point to the same commit

[ashleymercer]

I think this issue is essentially the same as #48 except in our case we might have multiple lightweight tags pointing to the same commit.

We have a build server which sometimes builds / tags the same commit multiple times (yes, this is a separate issue...) so we can end up with a git state that looks like:

 x <- HEAD, 0.1, 0.2
 |
 o

where 0.1 and 0.2 are lightweight tags. In this case sbt-dynver sometimes picks the "earlier" tag, which can then cause other problems for us.

I did some digging in the code: it looks like we use the output of git-describe in this line which, from what I can tell, is essentially unordered for lightweight tags since they don't contain any date information.

PS it looks like a similar issue was already fixed in sbt-git so we can take some inspiration from there for a fix.

[ashleymercer]

I think the fix is actually straightforward: make an extra call to list tags at the same commit, and perform some semver-sorting on them and pick the latest one. So we'd do something like:

> git describe --long --tags --abbrev=8 --match $TagPattern --always --dirty=+${timestamp(d)}
0.1

> git tag --list --points-at 0.1
0.1
0.2

We can now infer that the "correct" tag is 0.2, but use the commit distance and hash info from the original git describe (by definition this is still valid, since we only search for other tags which point to the same commit).

I think this covers all use cases:

• for the above case (HEAD and multiple tags on the same commit) it works
• if HEAD is ahead of the latest tag(s) it should still work - sbt-dynver will produce something like 0.2+1...

 x <- HEAD
 |
 x <- 0.1, 0.2
 |
 o

• it should (I think) also work transparently with any mixture of annotated and lightweight tags, since again in each case we only consider a single commit (points-at) and pick the "highest" one

If you're happy with this, I'm happy to have a go at putting a PR together?