[PR #161] [MERGED] fix: have current-version return biggest version if multiple tags point to a single commit #164

New issue

Closed

opened 2026-03-04 00:41:42 +03:00 by kerem · 0 comments

kerem commented

2026-03-04 00:41:42 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/thegeeklab/git-sv/pull/161
Author: @Strobotti
Created: 2/17/2025
Status: ✅ Merged
Merged: 2/17/2025
Merged by: @xoxys

Base: main ← Head: fix-current-version

📝 Commits (1)

6dfea87 fix: have current-version return biggest version if multiple tags point to a single commit

📊 Changes

1 file changed (+2 additions, -0 deletions)

View changed files

📝 app/app.go (+2 -0)

📄 Description

This PR fixes the issue where multiple release tags pointing to same commit doesn't return the latest tag deterministically. The issue is presented here:

$ git for-each-ref "refs/tags/v*" --sort -creatordate --format "%(refname:short) %(creatordate)" --count 5

v0.13.10 Tue Jan 7 16:27:06 2025 +0200
v0.13.11 Tue Jan 7 16:27:06 2025 +0200
v0.13.9 Tue Jan 7 16:27:06 2025 +0200
v0.13.8 Tue Jan 7 15:08:26 2025 +0200
v0.13.7 Tue Jan 7 14:55:10 2025 +0200

The count is here set to 5 to demonstrate the order in which the tags are returned.

The fix merely adds "-version:refname" -sort to the mix and thus always returns the biggest version number as the top result if there are multiple "latest tag" -candidates to choose from:

$ git for-each-ref "refs/tags/v*" --sort -version:refname --sort -creatordate --format "%(refname:short) %(creatordate)" --count 5

v0.13.11 Tue Jan 7 16:27:06 2025 +0200
v0.13.10 Tue Jan 7 16:27:06 2025 +0200
v0.13.9 Tue Jan 7 16:27:06 2025 +0200
v0.13.8 Tue Jan 7 15:08:26 2025 +0200
v0.13.7 Tue Jan 7 14:55:10 2025 +0200

I also opened an issue about this: https://github.com/thegeeklab/git-sv/issues/162

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/thegeeklab/git-sv/pull/161 **Author:** [@Strobotti](https://github.com/Strobotti) **Created:** 2/17/2025 **Status:** ✅ Merged **Merged:** 2/17/2025 **Merged by:** [@xoxys](https://github.com/xoxys) **Base:** `main` ← **Head:** `fix-current-version` --- ### 📝 Commits (1) - [`6dfea87`](https://github.com/thegeeklab/git-sv/commit/6dfea87667f6746b449796798cf24434b4113040) fix: have current-version return biggest version if multiple tags point to a single commit ### 📊 Changes **1 file changed** (+2 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `app/app.go` (+2 -0) </details> ### 📄 Description This PR fixes the issue where multiple release tags pointing to same commit doesn't return the latest tag deterministically. The issue is presented here: ```shell $ git for-each-ref "refs/tags/v*" --sort -creatordate --format "%(refname:short) %(creatordate)" --count 5 v0.13.10 Tue Jan 7 16:27:06 2025 +0200 v0.13.11 Tue Jan 7 16:27:06 2025 +0200 v0.13.9 Tue Jan 7 16:27:06 2025 +0200 v0.13.8 Tue Jan 7 15:08:26 2025 +0200 v0.13.7 Tue Jan 7 14:55:10 2025 +0200 ``` The count is here set to 5 to demonstrate the order in which the tags are returned. The fix merely adds "-version:refname" -sort to the mix and thus always returns the biggest version number as the top result if there are multiple "latest tag" -candidates to choose from: ```shell $ git for-each-ref "refs/tags/v*" --sort -version:refname --sort -creatordate --format "%(refname:short) %(creatordate)" --count 5 v0.13.11 Tue Jan 7 16:27:06 2025 +0200 v0.13.10 Tue Jan 7 16:27:06 2025 +0200 v0.13.9 Tue Jan 7 16:27:06 2025 +0200 v0.13.8 Tue Jan 7 15:08:26 2025 +0200 v0.13.7 Tue Jan 7 14:55:10 2025 +0200 ``` I also opened an issue about this: https://github.com/thegeeklab/git-sv/issues/162 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>