bootstrap.repos: origin comparison rejects ssh<->https remotes pointing at the same repo

[jeremy]

What happens

[bootstrap.repos] refuses to update an existing checkout when its origin uses a different transport than the configured url, even when both point at the same host and path:

[bootstrap.repos]
"~/src/docker-dev" = { url = "https://github.com/basecamp/docker-dev.git", ref = "master" }

With an existing checkout whose origin is git@github.com:basecamp/docker-dev.git:

$ mise bootstrap --only repos --yes
mise bootstrap: repos
mise ERROR repos: ~/src/docker-dev: origin does not match configured url

Reproduced on 2026.7.5 macos-arm64; main's normalize_remote_url has the same behavior (it normalizes only trailing slashes and a .git suffix).

Why this looks like a false positive

• The update path pulls via the checkout's own remote (git fetch/pull … origin in src/system/repos.rs), never via the configured url — so for same-host-same-path origins, the transport of the existing remote doesn't change what would be fetched.
• The existing .git-suffix normalization already treats the configured URL as identifying a repo rather than an exact string; ssh↔https is the same idea one step further.
• In fleet-bootstrap use (our case: converging dev machines that predate the declarative config), checkouts cloned over ssh — e.g. gh with git_protocol = ssh — hard-fail the repos phase until each user rewrites their remote, even though the checkout is the declared repo.

Proposal

Normalize both sides to host/path for the comparison — scp-like git@HOST:PATH and scheme://[user@]HOST/PATH forms — while keeping exact matching for file:// and local paths (as should_strip_git_suffix already distinguishes). Genuinely different remotes (different host, ssh alias, port, or path) would still conflict, which seems right.

Happy to PR this if the direction sounds acceptable.

[jdx]

This makes sense—the configured URL is acting as a repository identity check here, while updates continue to fetch and pull from the checkout’s existing origin.

A PR is welcome. Please normalize common network forms such as git@host:path, ssh://git@host/path, and https://host/path to a comparable host/path identity, while keeping different hosts or SSH aliases, explicit ports, and paths as conflicts. Local paths, file:// URLs, and unknown remote-helper syntax should continue to require exact matching. I would also avoid ignoring arbitrary SSH usernames since those can identify different repositories on generic SSH servers; treating the conventional git user as transport metadata covers the common forge case.

Please add positive SSH↔HTTPS coverage plus negative cases for different hosts, aliases, ports, paths, local/Windows paths, and non-git SSH users.

This comment was generated by an AI coding assistant.

[risu729]

This shipped in #11034 (fix(bootstrap): compare repo origins transport-agnostically), first released in v2026.7.8.

[bootstrap.repos] now compares the checkout's origin and the configured url by a transport-agnostic repository identity: git@host:path, ssh://git@host/path, and https://host/path forms of the same repo match (with .git/trailing-slash normalization and case-insensitive hosts), while different hosts, SSH aliases, explicit ports, non-git SSH users, and local/file:// paths still conflict — matching the spec laid out above. The original https↔ssh repro no longer reports a conflict.

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