You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes you work on projects where different branches are used for specific releases. Imagine a repository with a mature 1.9.21 release and an according branch and a brand new 2.0.3 release with according branch.
If you need to provide bugfixes and security updates for your 1.9.21 release you still need to create new minor and patch versions like 1.9.22. This is a typical use case and the git describe command works exactly as expected by returning the most git tag on this particular branch. Gtv on the other hand does not support this use case since we only update on the most recent version tag - which is 2.0.3. You can circumvent this by specifically setting a version to a specific commit with gtv set 1.9.22 abcdef987456 but the whole point of gtv is to simplify working with version tags.
Therefore, this request proposes a change so gtv works like git describe
# working on 1.x release
git checkout release_1.x.x
git describe
v1.9.21
git tag-version
2.0.3
# add a new patch to this specific release/branch
git tag-version new patch
git describe
v2.0.4
git tag-version
2.0.4
# switch to 2.x release
git checkout release_2.x.x
git describe
v2.0.3
git tag-version
2.0.4
The current implementation's behaviour is quirky, unexpected and undocumented as well.
The text was updated successfully, but these errors were encountered:
Sometimes you work on projects where different branches are used for specific releases. Imagine a repository with a mature 1.9.21 release and an according branch and a brand new 2.0.3 release with according branch.
If you need to provide bugfixes and security updates for your 1.9.21 release you still need to create new minor and patch versions like 1.9.22. This is a typical use case and the
git describe
command works exactly as expected by returning the most git tag on this particular branch. Gtv on the other hand does not support this use case since we only update on the most recent version tag - which is 2.0.3. You can circumvent this by specifically setting a version to a specific commit withgtv set 1.9.22 abcdef987456
but the whole point of gtv is to simplify working with version tags.Therefore, this request proposes a change so gtv works like
git describe
The current implementation's behaviour is quirky, unexpected and undocumented as well.
The text was updated successfully, but these errors were encountered: