Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ashleymercer opened this issue Dec 3, 2022 · 1 comment

Comments

@ashleymercer
Copy link

ashleymercer commented Dec 3, 2022

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
Copy link
Author

ashleymercer commented Dec 3, 2022

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant