-
So I'm using this great package and all has been well for some time now. However, recently I made a change to a pipeline on Gitlab where I now commit something at the same time as tagging a commit. Basically I went from: - git tag version -m "something"
- git push origin version --no-verify to - git commit -a -m "something"
- git tag version -m "something"
- git push origin version --no-verify and now I'm starting to see minver not calculate the correct version number, at least on my local build. The tags exist exactly as I would expect in the Gitlab interface and using This is the output from minver with verbose logging:
The calculated version is 0.4.16. Why exactly are those 0.5.* being ignored? Do I have to do this in two separate pushes for some reason? Am I misunderstanding something git-related here? I use MinVer 2.5.0 from NuGet. Any help appreciated! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
@Capsup the commits which are tagged 0.5.x do not appear anywhere in the history of the current commit. You can see this by searching for the SHA. E.g.
Although the 0.5.x tags exist in your repo, they must be on another branch, or a commit which is later in the history than the current commit. |
Beta Was this translation helpful? Give feedback.
@Capsup the commits which are tagged 0.5.x do not appear anywhere in the history of the current commit. You can see this by searching for the SHA. E.g.
86cce706306afc41e42d133c8279fcb63b0ff067
does not appear anywhere in the git log (try searching for that string in this web page). This hold true for all the commits shown against the 0.5.x tags. Whereas the commits against the 0.4.x tags do appear in the git log.Although the 0.5.x tags exist in your repo, they must be on another branch, or a commit which is later in the history than the current commit.