Inconsistent versionning after intermediary commit #93

Open
jeantil opened this Issue Jul 15, 2015 · 4 comments

Comments

Projects
None yet
4 participants
@jeantil

jeantil commented Jul 15, 2015

With a git base version at 0.1in a new repository with one commit
I expect the version to be 0.1-xxxxxxxxxx where xxxxxxxxxx is the sha1 of the commit

If I tag the commit v1.0.0,
I expect the version to be 1.0.0

If I add a file without committing,
I expect the version to be 1.0.0-SNAPSHOT

If I commit the newly added file (and get the new sha1 yyyyyyyy)
I expect the version to be 1.0.0-yyyyyyyy or 1.0.0-yyyyyyy-SNAPSHOT

This fails and reverts back to 0.1-yyyyyyyy

Following is an sbt-test test case for the issue , it fails on line 25 with a version which has reverted to 0.1-yyyyyyyy instead of 1.0.0-yyyyyyyy or 1.0.0-yyyyyyyy-SNAPSHOT or maybe 1.0.0-SNAPSHOT

git init
git config user.email "test@jsuereth.com"
git config user.name "Tester"
git add README.md
git commit -m "test"
$ copy-file changes/build.sbt build.sbt
reload
inspect version
checkVersionStartsWith 0.1
git add build.sbt
git commit -m"v1.0.0"
git tag v1.0.0
reload
inspect version
checkVersion 1.0.0
$ copy-file changes/change1.txt change1.txt
git add change1.txt
reload
inspect version
checkVersionStartsWith 1.0.0
checkSnapshotVersion
git commit -m"v1.0.1"
reload
inspect version
checkVersionStartsWith 1.0.0

@oliverlockwood

This comment has been minimized.

Show comment
Hide comment
@oliverlockwood

oliverlockwood Jun 13, 2017

Contributor

I came across this while digging this week.

The problem is that the gitCurrentTags settings only looks for tags matching the commit at HEAD.
This is caused by the matching logic here.

I've put together a candidate fix in #135 for discussion.

Contributor

oliverlockwood commented Jun 13, 2017

I came across this while digging this week.

The problem is that the gitCurrentTags settings only looks for tags matching the commit at HEAD.
This is caused by the matching logic here.

I've put together a candidate fix in #135 for discussion.

@dcecile

This comment has been minimized.

Show comment
Hide comment
@dcecile

dcecile Jun 8, 2018

@oliverlockwood @dwijnand Was #149 PR the replacement for #135 PR? If so, now that #149 is merged, is this issue (intermediary commits) now resolved?

dcecile commented Jun 8, 2018

@oliverlockwood @dwijnand Was #149 PR the replacement for #135 PR? If so, now that #149 is merged, is this issue (intermediary commits) now resolved?

@oliverlockwood

This comment has been minimized.

Show comment
Hide comment
@oliverlockwood

oliverlockwood Jun 8, 2018

Contributor

@dcecile It depends how you look at it 😄

The exactly issue raised by @jeantil is not directly fixed, because as per my #93 (comment) above, there's still direct checking against tags matching the current commit, instead of a search to find reachable tags in the history.

However, if you set git.useGitDescribe := true, then this flawed code isn't used; instead, JGit's enhanced describe functionality does the work for you.

Contributor

oliverlockwood commented Jun 8, 2018

@dcecile It depends how you look at it 😄

The exactly issue raised by @jeantil is not directly fixed, because as per my #93 (comment) above, there's still direct checking against tags matching the current commit, instead of a search to find reachable tags in the history.

However, if you set git.useGitDescribe := true, then this flawed code isn't used; instead, JGit's enhanced describe functionality does the work for you.

@dcecile

This comment has been minimized.

Show comment
Hide comment
@dcecile

dcecile Jun 8, 2018

@oliverlockwood OK, thanks for the explanation! 🙏

dcecile commented Jun 8, 2018

@oliverlockwood OK, thanks for the explanation! 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment