[jdx]

A github:-backed tool whose release tags repeat the configured version_prefix listed versions that could not be installed back.

With this config:

[tools."github:example/tool"]
version = "a-1.2.3"
version_prefix = "a-"

and the upstream tag a-a-1.2.3, mise ls-remote prints a-1.2.3 — the prefix is stripped once, so the listed version still starts with the prefix. On install, mise reconstructed the tag from that version as a-1.2.3 and then 1.2.3, and never tried a-a-1.2.3. Every listed version for such a repo failed to install, including whatever latest resolved to.

What changed

• When a version_prefix is configured, prefix + version is now tried first even when the version already starts with the prefix. That candidate is the only one that names the tag the version was listed from, so a listed version always round-trips to its own tag.
• Stripping the prefix off a requested version now tries one copy removed first, mirroring how the version was listed, before falling back to every copy removed (which is all the old trim_start_matches did). Nothing that used to resolve stops resolving; the better guess just goes first.
• Candidate tags are built by a new pure tag_candidates helper and deduplicated, so an empty or self-matching prefix no longer spends two HTTP requests on the same tag.

Before, a-1.2.3 with version_prefix = "a-" produced the candidates a-1.2.3, 1.2.3. It now produces a-a-1.2.3, a-1.2.3, 1.2.3.

Nothing that resolved before stops resolving — the bare version is still tried, just second. The one behavior change: if a repo publishes both a-1.2.3 and a-a-1.2.3, the version string a-1.2.3 now resolves to a-a-1.2.3. That is the correct reading, since a-1.2.3 is what mise lists for the doubled tag, but someone hand-writing the shorter tag pays one extra 404 and gets the other release. This is documented on tag_candidates.

strip_version_prefix is unchanged: it already strips a single prefix, which the install path can now invert. Making it refuse to strip ambiguous tags would change what ls-remote prints without fixing anything.

Validation

Three new unit tests in src/backend/static_helpers.rs fail on the old logic and pass on the new one — two over tag_candidates directly, and one #[tokio::test] end to end through try_with_v_prefix_and_repo where only the real tag a-a-1.2.3 resolves. A fourth pins the no-prefix candidate order, and test_version_prefix_functionality in src/backend/github.rs now pins the listing side of the round-trip.

Unit tests only: the bug is entirely in candidate construction, and an e2e test would need a public repo that actually ships a doubled-prefix tag.

cargo test --bin mise backend:: passes (704), and cargo clippy --workspace --all-features --all-targets -- -D warnings is clean.

Raised by a review bot on #13308 and deliberately left out of it; that PR only changes an error message, and the version it suggests is the same string mise lists everywhere, so it stays as is.

🤖 Generated with Claude Code

AI-assisted — Tool: Claude Code; model: anthropic/claude-opus-5; version: unavailable.

---

Note

Medium Risk
Changes GitHub release tag resolution order for prefixed versions; mostly fixes broken installs but can prefer a different tag when both short and doubled-prefix releases exist.

Overview
Fixes GitHub backend installs when release tags repeat the configured version_prefix (e.g. tag a-a-1.2.3 with version_prefix = "a-" listed as a-1.2.3). Install no longer stops at wrong reconstructions like a-1.2.3 / 1.2.3 and skips the real tag.

Tag lookup is refactored around a new tag_candidates helper used by try_with_v_prefix_and_repo. With a custom prefix, prefix + version is tried first even when the version already starts with that prefix, so listed versions round-trip to their source tag. Prefix stripping on candidates uses one strip_prefix step (matching listing) before a last-resort full trim_start_matches. Candidates are deduplicated so empty or redundant prefixes do not double-fetch the same tag.

Tests cover repeated-prefix listing/install, candidate ordering, deduplication, and an async resolver path; strip_version_prefix in github.rs documents the doubled-prefix listing case.

Behavior note: if both a-1.2.3 and a-a-1.2.3 exist, requesting a-1.2.3 now prefers the tag mise would list for the doubled form (a-a-1.2.3).

^{Reviewed by Cursor Bugbot for commit 6cd301a. Bugbot is set up for automated code reviews on this repo. Configure here.}

Summary by CodeRabbit

• Bug Fixes

  • Improved release tag resolution for versions that already include the configured prefix.
  • Preserved the correct prefix when processing versions with repeated prefix text.
  • Added more reliable fallback handling for alternate release-tag formats.
  • Prevented redundant release-tag lookups for duplicate candidates.

• Tests

  • Added coverage for repeated prefixes, fallback behavior, candidate ordering, and duplicate tag handling.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited), Organization UI (inherited)

Review profile: CHILL

Plan: Advanced

Run ID: 5aee71fa-7046-4d21-8dba-060f90536721

📥 Commits

Reviewing files that changed from the base of the PR and between 2ddc377 and 6cd301a.

📒 Files selected for processing (1)

• src/backend/static_helpers.rs

Included review availability: Your plan provides up to 10 included reviews per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

tag_candidates now builds ordered, deduplicated release-tag candidates. try_with_v_prefix_and_repo uses these candidates. Tests cover repeated prefixes, fallback ordering, repository-qualified tags, and no-prefix behavior.

Changes

GitHub tag resolution

Layer / File(s)	Summary
Prefix-aware candidate generation and regression coverage src/backend/static_helpers.rs, src/backend/github.rs	tag_candidates tries prefixed, original, single-stripped, and fully stripped versions in order. Tests cover repeated prefixes, deduplication, fallback ordering, and no-prefix candidates.
Resolver integration src/backend/static_helpers.rs	try_with_v_prefix_and_repo iterates over the generated candidates while retaining its existing success and error handling.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: risu729

Merge Risk: ⚪ Minimal · up to 6cd30

The release-tag resolution update has no identified merge-blocking issue.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 11 functions across 2 files.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: fixing installation for versions whose GitHub tags repeat the configured version_prefix.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge; the previous fallback regression is fixed without introducing a new actionable issue.

Summary

This PR fixes round-trip installation of release tags that repeat a configured version_prefix.

• Extracts ordered tag construction into the pure tag_candidates helper.
• Reconstructs repeated-prefix tags while preserving prefixed, unprefixed, and fully stripped fallbacks.
• Deduplicates equivalent candidates to avoid redundant resolver requests.
• Adds focused tests for repeated prefixes, fallback ordering, deduplication, no-prefix behavior, and resolver integration.

_{Reviews (2) · Last reviewed commit: "fix(github): keep the fully-stripped tag..."}

[github-actions]

Instruction counts

benchmark	trend	instructions	Δ	wall (min)	Δ
env	█▃▃▁▂▃▁▅▄▅▅▁▂	35,638,687 → 35,658,213	+0.05%	18.88 → 19.61ms	+3.89%
hook-env	█▇▃▇▄▇▇▇▅█▅▃▁	37,146,582 → 37,113,852	-0.09%	19.47 → 20.25ms	+4.02%
ls	▅█▇█▇█▆▇▇█▇▆▁	40,056,558 → 39,832,526	-0.56%	21.92 → 22.13ms	+0.97%
registry	▆▅▅▅▅▅██▅▆█▄▁	38,236,809 → 38,161,224	-0.20%	16.92 → 16.12ms	-4.76%
startup	█▇▆▆▂▃▄▄▇▇▆▄▁	9,509,828 → 9,493,852	-0.17%	10.68 → 11.31ms	+5.88%

No instruction-count regression above 1%.

_{Only instruction counts gate. Wall clock is shown for context — on identical hardware it moves 4-20% run to run.}

_{Measured by tak — instruction-counted CLI benchmarks, stored in this repository's git notes.}

_{6cd301aa1799 vs 9e5ee1a36af5 · measured on the runner, not pushed to the history.}