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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Old tag is selected when two tags reference same commit #48

Closed
olafurpg opened this issue Sep 11, 2017 · 8 comments
Closed

Old tag is selected when two tags reference same commit #48

olafurpg opened this issue Sep 11, 2017 · 8 comments
Assignees

Comments

@olafurpg
Copy link
Member

We were just releasing scalameta v2.0.0 (馃帀 ) and the v2.0.0 tag points to the same commit as the v2.0.0-RC3 tag, which we released a few days ago. sbt-dynver selected the version v2.0.0-RC3 when we pushed the v2.0.0 tag, see https://travis-ci.org/scalameta/scalameta/jobs/274261204#L671, causing publish to fail.

Tag v2.0.0
...
[info] Welcome to scalameta 2.0.0-RC3

I expected the version number to be 2.0.0.

@dwijnand dwijnand added the bug label Sep 12, 2017
@dwijnand
Copy link
Member

Interesting - I thought I'd checked this case, but clearly not, sorry.

You at Scala World, Olaf? Could see to fix it then (me/you/together).

@dwijnand dwijnand self-assigned this Sep 12, 2017
@olafurpg
Copy link
Member Author

Yes, I'll be there! Sounds like a good bugfix for the SC Spree 馃槃

@dwijnand dwijnand removed the bug label Oct 18, 2017
@samudurand
Copy link

Is there any progress on that issue ? Ideally we would like to have this fantastic plugin to choose the most recent tag. Or just the most recent version (v0.0.6 instead of v0.0.5 for instance) by simple string comparison maybe ?

@dwijnand
Copy link
Member

dwijnand commented Nov 6, 2017

I've not had a chance to look at this. Contributions welcome if they catch your fancy.

@samudurand
Copy link

Might, do, any hint on where to look for the change to make @dwijnand @olafurpg ? I currently don't have the time for digging into the whole code without any starting point. Otherwhise it will have to wait

@dwijnand
Copy link
Member

dwijnand commented Nov 6, 2017

Everything comes from one invocation of git describe: https://github.com/dwijnand/sbt-dynver/blob/v2.0.0/src/main/scala/sbtdynver/DynVerPlugin.scala#L121

Ideally there would be a flag for that that deals with this edge-case.

For testing (e.g to TDD your way to a solution) you could look to create a test similar to https://github.com/dwijnand/sbt-dynver/blob/v2.0.0/src/test/scala/sbtdynver/GH007.scala.

@dwijnand
Copy link
Member

dwijnand commented Jan 4, 2018

Hey @olafurpg,

I tried to reproduce this, but couldn't:

$ git init
Initialized empty Git repository in /s/t-git-multi-tag/.git/
$ echo 1 > f.txt
$ git add f.txt
$ git commit -m1
[master (root-commit) 6eda7fa] 1
 1 file changed, 1 insertion(+)
 create mode 100644 f.txt

$ git tag -a -s v2.0.0-RC3 -m 'Version 2.0.0-RC3'
$ git describe --tags --abbrev=8 --match v[0-9]* --always --dirty=+20180104-1200
v2.0.0-RC3

$ git tag -a -s v2.0.0 -m 'Version 2.0.0'
$ git describe --tags --abbrev=8 --match v[0-9]* --always --dirty=+20180104-1200
v2.0.0

Then I found this in the "SEARCH STRATEGY" section of git describe:

Annotated tags will always be preferred over lightweight tags, and tags with newer dates will always be preferred over tags with older dates.

(https://www.kernel.org/pub/software/scm/git/docs/git-describe.html#_search_strategy)

Initially I thought that the problem was that my reproduction wasn't faithfully reproducing the tag dates.

Instead it looks like the issue is that the v2.0.0 tag of Scalameta is a lightweight tag, while v2.0.0-RC3 is a proper annotated tag:

$ git show v2.0.0-RC3
tag v2.0.0-RC3
Tagger: 脫lafur P谩ll Geirsson <olafurpg@gmail.com>
Date:   Wed Sep 6 11:49:04 2017 +0200

See #1109

commit 15a0187501dc8e5a6fe06d0e002ce1d3340968dc (tag: v2.0.0-RC3)
Merge: de1f4f2d5 10a2c60b0
Author: 脫lafur P谩ll Geirsson <olafurpg@gmail.com>
Date:   Wed Sep 6 11:46:47 2017 +0200

    Merge pull request #1113 from olafurpg/ci-publish

    Fix CI publish infrastructure

$ git show v2.0.0
commit fa0dc78783b5cb26b17ee32eec5536d36915c82e (tag: v2.0.0)
Merge: 15a018750 c89ad57d7
Author: 脫lafur P谩ll Geirsson <olafurpg@gmail.com>
Date:   Mon Sep 11 19:53:06 2017 +0200

    Merge pull request #1118 from olafurpg/master

    Redirect changelog files to GitHub releases.

I assume the tag was created with the GitHub Releases UI.

By default git describe never considers lightweight tags, we actually opt-ed into lightweight tags specifically for GitHub's Releases UI (see #14) by adding the --tags flag. Generally (IMHO) the difference isn't known by git users.

Unfortunately it doesn't look like there is a flag to make git describe ignore the annotated vs lightweight tag difference and only consider the dates. And even then I'm not 100% sure if that would be a good idea.

Running out of ideas I'm going to close this, but please comment if you have any ideas or thoughts.

@olafurpg
Copy link
Member Author

olafurpg commented Jan 4, 2018

Interesting. Thanks for digging into this @dwijnand I did indeed publish v2.0.0 from the GitHub release UI and iirc I tagged v2.0.0-RC3 locally. I didn't know about lightweight vs. annotated tags.

Totally fine to close this issue then 馃憤

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

3 participants