repo rename and transfer: port the CLI half from 4a5d5d2 (#10) #3

• 
  @ogirardot opened this merge request · Sep 7, 2026

  Closes #10.

  rickub/rickub!120 shipped repo rename and transfer across both halves. When it
  landed, cli/ had already moved to this repository, so the merge hit five
  modify/delete conflicts — all under cli/ — and they were resolved by dropping
  the CLI half. The API has been live and uncallable from the terminal ever since,
  with the only record a comment on a merged MR.

  Ported, not rewritten, from 4a5d5d2 as the issue asks — including
  cli/cmd/repo_test.go's cases, which came with the original work.

  rickub repo rename   <owner/repo> <new-name>
  rickub repo transfer <owner/repo> <new-owner>
  

  • internal/api: RenameRepo / TransferRepo over POST .../rename and
    POST .../transfer, with RepoRename{name} / RepoTransfer{new_owner} —
    checked field-for-field against the live handlers' repoRenameBody /
    repoTransferBody in web/api_repos.go, not just against the ported diff.
  • cmd/repo.go: both commands ExactArgs(2), both routing the spec through the
    shared parseOwnerRepo.

  Two deliberate divergences from the ported commit

  This repo moved on after the split, so the port is adapted rather than applied
  verbatim:

  1. The printed FullName goes through clean(), like every other
     server-provided string since the b7e1d1f hardening — which postdates 4a5d5d2.
  2. One extra test: a spec without a slash must be refused before any request, the
     rule repo view and repo delete already follow.

  Verified live

  End to end against rickub.com on a throwaway repo, not only in tests:

  step	result
  repo rename ogirardot/cli-move-smoke cli-move-smoke-renamed	Renamed to ogirardot/cli-move-smoke-renamed
  repo transfer … rickub	Transferred to rickub/cli-move-smoke-renamed
  rename again in the new namespace, --json	full repo object at the new path
  repo rename cli-move-smoke-renamed x (no slash)	expected owner/repo, got …, no request
  repo transfer … no-such-org-xyz	server's forbidden_owner, surfaced cleanly

  The throwaway repo was deleted afterwards.

  🤖 Generated with Claude Code

  https://claude.ai/code/session_01KPPhRdTiUiiSvLjthotkT1

• 
  @ogirardot · Sep 7, 2026

  Reviewed at effort high; two findings, both fixed. The reviewer also cross-checked
  the port against the monorepo source and the live handlers (web/api_repos.go,
  service.go's MoveRepo) and confirmed paths, methods and body field names match.

  1. TestRepoMoveArgCount did not test what it claimed (medium). It came over
  from 4a5d5d2 setting only XDG_CONFIG_HOME and no token, so newClient() failed
  before the ExactArgs(2) guard was ever reached — the assertion passed whether or
  not the guard existed. Confirmed by relaxing rename to MinimumNArgs(1): the
  test stayed green, while the same code panics on args[1] in real use.

  It now runs against the stub server with a token and host, asserts the error text
  is accepts 2 arg(s), and asserts nothing reached the server. Re-checked against
  the relaxed guard: it fails now, as it should.

  2. repo transfer had no confirmation (low/medium). repo delete, twenty
  lines below, makes you type the repo name; transfer fired on one keystroke. And
  transfer is the stronger one-way door of the two — after the move the actor may
  hold no ADMIN in the destination namespace, so transferring back answers
  forbidden_owner. It confirms the same way now, with --yes for scripts.

  rename deliberately stays unprompted. It breaks every clone URL, which is why the
  help says so, but the actor keeps ADMIN and can rename straight back — there is no
  door to close, and a prompt on every rename would be friction without a reason. A
  test pins both halves of that decision.

  This makes three divergences from the ported commit rather than the two the MR
  description lists, all because this repo moved on after the split: clean() on
  human output (b7e1d1f), the no-slash spec test, and now the transfer prompt.

  Verified live on a throwaway repo: a mistyped confirmation aborts and the repo
  stays where it was, the correct answer goes through, --yes skips the prompt. The
  repo was deleted afterwards.

Sign in to comment.