Sort git tags when determining prerelease version#2331
Conversation
Tags are sorted lexicographically by default, not by version, so for example right now `git ls-remote` for this repo shows: ``` $ git ls-remote --tags \ https://github.com/github/copilot-cli \ | tail -3 | awk -F/ '{print$NF}' v1.0.8 v1.0.8-0 v1.0.9 ``` With the sort option, it shows the correct latest prerelease tags: ``` $ git ls-remote --tags --sort "version:refname" \ https://github.com/github/copilot-cli \ | tail -3 | awk -F/ '{print$NF}' v1.0.12-0 v1.0.12-1 v1.0.12-2 ``` This option for git ls-remote was added in git version 2.18.0 in June 2018: https://github.com/git/git/blob/v2.18.0/Documentation/RelNotes/2.18.0.txt#L69-L70
There was a problem hiding this comment.
Pull request overview
Updates the install script’s prerelease resolution to sort git tags by version so the “latest” prerelease tag can be identified reliably (instead of lexicographic ordering).
Changes:
- Add
--sort "version:refname"to thegit ls-remote --tagscall used for prerelease version discovery.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| exit 1 | ||
| fi | ||
| VERSION="$(git ls-remote --tags "$GIT_REMOTE" | tail -1 | awk -F/ '{print $NF}')" | ||
| VERSION="$(git ls-remote --tags --sort "version:refname" "$GIT_REMOTE" | tail -1 | awk -F/ '{print $NF}')" |
There was a problem hiding this comment.
git ls-remote --tags --sort "version:refname" ... requires git >= 2.18.0; on older systems this will exit non-zero and, with set -e, abort prerelease installs. Consider detecting support (e.g., probe git ls-remote --help/git --version) and falling back to a portable sort (like sorting the tag names locally) when --sort isn't available.
| VERSION="$(git ls-remote --tags --sort "version:refname" "$GIT_REMOTE" | tail -1 | awk -F/ '{print $NF}')" | |
| # Prefer using git's built-in tag sorting when available (git >= 2.18.0), | |
| # but fall back to a portable local sort for older git versions. | |
| if git ls-remote --help 2>&1 | grep -q -- '--sort'; then | |
| VERSION="$(git ls-remote --tags --sort="version:refname" "$GIT_REMOTE" | tail -1 | awk -F/ '{print $NF}')" | |
| else | |
| VERSION="$(git ls-remote --tags "$GIT_REMOTE" \ | |
| | awk '{print $2}' \ | |
| | awk -F/ '{print $NF}' \ | |
| | sort -V \ | |
| | tail -1)" | |
| fi |
There was a problem hiding this comment.
Git 2.18 came out in 2018, which you might believe to be ancient history, but I half-expect to hear from some CentOS user about this. Then again, they're also probably not going to be able to run the binary at all, so I'll let it slide.
| exit 1 | ||
| fi | ||
| VERSION="$(git ls-remote --tags "$GIT_REMOTE" | tail -1 | awk -F/ '{print $NF}')" | ||
| VERSION="$(git ls-remote --tags --sort "version:refname" "$GIT_REMOTE" | tail -1 | awk -F/ '{print $NF}')" |
There was a problem hiding this comment.
This branch is documented as “Get the latest prerelease tag”, but the command picks the highest overall version tag. If a stable tag (e.g. v1.0.12) exists, this will resolve to the stable release rather than a prerelease (e.g. v1.0.12-2). Consider filtering to prerelease tags (e.g. tags containing -) before selecting the latest.
| VERSION="$(git ls-remote --tags --sort "version:refname" "$GIT_REMOTE" | tail -1 | awk -F/ '{print $NF}')" | |
| VERSION="$(git ls-remote --tags --sort "version:refname" "$GIT_REMOTE" 'refs/tags/*-*' | tail -1 | awk -F/ '{print $NF}')" |
Hello! I hope you're having a nice day. :)
Tags are sorted lexicographically by default, not by version, so for example right now
git ls-remotefor this repo shows:With the sort option, it shows the correct latest prerelease tags:
This option for
git ls-remotewas added in git version 2.18.0 in June 2018:https://github.com/git/git/blob/v2.18.0/Documentation/RelNotes/2.18.0.txt#L69-L70
so I would hope it's pretty well established out there at this point.
I noticed there's an open issue for
npm installprerelease -- #2327 -- but the numbers there don't seem to line up with what I'm seeing, so might be completely unrelated. For what it's worth, at this time that installation method is getting the latest non-prerelease, as though@prereleaseis being ignored entirely, rather than getting a bad sort like this.