fix(mkrep): make origin linking idempotent #155

2026-09-16T23:38:18Z

rootiest commented

2026-09-16 23:38:18 +00:00

Problem

Both of mkrep's remote-linking paths — --remote, and the --server/$GIT_SERVER branch that links when the repo already exists on the forge — called git remote add origin bare:

error: remote origin already exists.
✘  Failed to add remote git@example.com:me/existing.git
STATUS=1

That is the normal outcome, not an edge case. mkrep . against an existing checkout works exactly as documented — nothing in the function gates on the directory being new, is_new only picks which message prints — so pointing it at a directory that is already linked, or simply rerunning it against the same target, fails the whole call with exit 1 after the local work has already succeeded.

Fix

Route both call sites through a new _mkrep_add_origin helper:

no origin yet → add it
origin already pointing at the requested URL → report it and succeed, since the requested end state already holds
origin pointing somewhere else → refuse, naming both URLs and the git remote set-url that would repoint it

A different URL is a different repository. Silently repointing an existing checkout is the worse failure mode — an origin the caller never mentioned is more likely a mistargeted mkrep than one that wants rewriting — so that stays an explicit decision.

Fixing this in the shared helper rather than at each call site also means the --server link-existing path gets it, which is where a rerun is most likely: that branch exists precisely because the repo was found on the forge already.

Not covered: --new-remote and the built-in --server create templates run git remote add origin inside the user's own command string, which is outside mkrep's reach.

Verification

New section in tests/test-mkrep.fish covering the rerun (exit 0, one origin, URL untouched) and the conflicting-URL refusal (exit 1, origin left alone).
fish tests/run-tests.fish — 758/758 assertions, exit 0.
python3 docs/verify-manual.py — 84/84.
Manual check of the original repro: first run links, second run reports "origin already points at …" and exits 0, a third run with a different URL exits 1 with origin unchanged.

Docs live in the function header (SSOT); the generated manual and man page regenerate in CI on main.

## Problem Both of mkrep's remote-linking paths — `--remote`, and the `--server`/`$GIT_SERVER` branch that links when the repo already exists on the forge — called `git remote add origin` bare: ``` error: remote origin already exists. ✘ Failed to add remote git@example.com:me/existing.git STATUS=1 ``` That is the normal outcome, not an edge case. `mkrep .` against an existing checkout works exactly as documented — nothing in the function gates on the directory being new, `is_new` only picks which message prints — so pointing it at a directory that is already linked, or simply rerunning it against the same target, fails the whole call with exit 1 after the local work has already succeeded. ## Fix Route both call sites through a new `_mkrep_add_origin` helper: - no origin yet → add it - origin already pointing at the requested URL → report it and succeed, since the requested end state already holds - origin pointing somewhere else → refuse, naming both URLs and the `git remote set-url` that would repoint it A different URL is a different repository. Silently repointing an existing checkout is the worse failure mode — an origin the caller never mentioned is more likely a mistargeted mkrep than one that wants rewriting — so that stays an explicit decision. Fixing this in the shared helper rather than at each call site also means the `--server` link-existing path gets it, which is where a rerun is most likely: that branch exists precisely because the repo was found on the forge already. Not covered: `--new-remote` and the built-in `--server` create templates run `git remote add origin` inside the user's own command string, which is outside mkrep's reach. ## Verification - New section in `tests/test-mkrep.fish` covering the rerun (exit 0, one origin, URL untouched) and the conflicting-URL refusal (exit 1, origin left alone). - `fish tests/run-tests.fish` — 758/758 assertions, exit 0. - `python3 docs/verify-manual.py` — 84/84. - Manual check of the original repro: first run links, second run reports "origin already points at …" and exits 0, a third run with a different URL exits 1 with origin unchanged. Docs live in the function header (SSOT); the generated manual and man page regenerate in CI on `main`.

rootiest added the Kind/Bug Area/Functions Area/Tests labels 2026-09-16 23:38:18 +00:00

rootiest added 1 commit 2026-09-16 23:38:19 +00:00

fix(mkrep): make origin linking idempotent a09d3db800

Both link paths -- --remote and the --server/$GIT_SERVER link-existing
branch -- called `git remote add origin` bare. That fails with "remote
origin already exists" whenever the target is already linked, which is
the normal case for `mkrep .` against an existing checkout and for any
rerun against the same target. The failure took the whole call down with
exit 1.

Route both through a new _mkrep_add_origin helper: add when there is no
origin, accept and report when origin already points at the requested
URL, and refuse when it points elsewhere. A different URL is a different
repo, so repointing stays the caller's explicit decision rather than a
silent rewrite of a checkout mkrep may have been aimed at by mistake.

rootiest merged commit 00606ecdca into main

2026-09-16 23:39:30 +00:00

rootiest deleted branch fix/mkrep-origin-idempotent

2026-09-16 23:39:30 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: rootiest/fish-config#155