git remote para coding agents: listar, no reescribir origin

git remote no es “cambia origin para que el push pase”. El man (git-remote(1); git-scm.com/docs/git-remote HTTP 200): administra el set de repositorios rastreados. Sin argumentos lista los remotes. -v / --verbose va entre remote y el subcomando; muestra la URL. Un coding agent lee origin; no lo reescribe.

GitHub Docs (HTTP 200, 2026-09-04, Managing remote repositories): git remote add toma dos argumentos — un nombre (origin) y una URL (https://github.com/OWNER/REPOSITORY.git). git remote -v verifica. Si el nombre ya existe: fatal: remote origin already exists. El man (EXIT STATUS): exit 3. Contrato: listar; añadir solo un nombre nuevo; cero --mirror; cero git://.

Qué es un remote (oficial)

DISCUSSION del man: la config vive en remote.origin.url y remote.origin.fetch (git-config(1)). GitHub Docs (About remote repositories): Git asocia una URL con un nombre; el default suele ser origin.

git remote -v
git remote get-url origin
git remote get-url --push origin

-v antes del subcomando. get-url expande insteadOf / pushInsteadOf; default = primera URL. --push consulta URLs de push. --all lista todas.

Lo que el agente sí / no corre

Quiero	Comando	Trampa
¿Qué remotes hay?	git remote -v	remote al LLM sin -v
URL de origin	get-url origin	set-url origin “para arreglar auth”
Segundo remoto (upstream)	remote add upstream <url>	remote add origin otra vez
Limpiar refs muertos	prune --dry-run primero	prune a ciegas
Traer objetos	fetch	remote update de todos

Prohibido en autónomo:

• remote add origin si origin ya existe. GitHub Docs: el error significa que el nombre ya está. El man: exit 3. Usa otro nombre, o no toques origin.
• remove / rm origin. El man: borra el remote, todos los remote-tracking y su config. Un agente no deja el repo sin origin.
• set-url origin a otro host “porque el fetch falló”. GitHub Docs: set-url cambia la URL de un remote existente. Auth rota → secretos / PAT, no otra URL.
• --mirror=fetch / --mirror=push en add. El man: --mirror=fetch espeja refs/ del remoto directo a refs/ local; “only makes sense in bare repositories, because a fetch would overwrite any local commits”. --mirror=push hace que todo git push se comporte como --mirror.
• git://. GitHub Docs: HTTPS (https://github.com/OWNER/REPOSITORY.git) o SSH ([email protected]:OWNER/REPOSITORY.git). Password-based auth en GitHub ya no existe; PAT o credential helper. Un agente no usa git://.
• Fetch URL y push URL a sitios distintos en el mismo remote. El man (set-url): “must still refer to the same place”. Si fetches upstream y pusheas a tu fork: dos remotes, no un set-url --push a otro host.
• remote update sin nombre. El man: actualiza el grupo remotes.default o todos los remotes sin skipDefaultUpdate. Un agente nombra el remote y corre fetch.
• prune sin --dry-run. El man: equivale a git fetch --prune sin traer refs nuevos; según config puede podar tags locales no pusheados. --dry-run primero.

-f en add corre git fetch <name> al terminar. --tags importa todos los tags; --no-tags no importa ninguno. Default: solo tags de las ramas fetcheadas. -t <branch> rastrea esa rama, no el glob refs/remotes/<name>/. Un agente no estrecha origin “para ir más rápido”.

Receta (60 segundos)

Solo en un worktree propio:

git remote -v
git remote get-url origin

Si hace falta el upstream del fork y no existe:

git remote add upstream https://github.com/OWNER/REPOSITORY.git
git remote -v
git fetch upstream

Si add origin explota (exit 3): no borres origin. GitHub Docs: otro nombre, o deja el que ya está.

set-head origin -a pregunta el HEAD del remoto y apunta refs/remotes/origin/HEAD. El man: solo si refs/remotes/origin/<rama> ya existe; si no, fetch primero. Un agente no borra ese symbolic-ref (-d).

Cierre del trabajo: push a tu rama + PR, no un set-url origin “al repo de prod”.

set-url, prune y el mismo lugar

set-url [--push] <name> <newurl> [<oldurl>]: el man cambia la primera URL que matchee el regex <oldurl>. Sin match: error, nada cambia. --add agrega; --delete borra las que matchean. Borrar todas las URLs de fetch es error.

show <name> consulta heads con git ls-remote salvo -n (cache). No vuelques show entero al prompt.

rename <old> <new> actualiza remote-tracking y config. Un agente no renombra origin.

Checklist

• Lectura: git remote -v y get-url. Cero dump de show al LLM.
• Origin se respeta. Cero remove origin / add origin si ya existe (exit 3).
• Segundo remoto = otro nombre. Cero set-url a otro host para “arreglar” auth.
• Fetch URL y push URL = el mismo lugar. Si no, dos remotes.
• Cero --mirror=fetch / --mirror=push. Cero git://.
• prune --dry-run antes de podar. Cierre = PR, no un origin nuevo.

FAQ

¿git remote -v add es el orden? No. El man: -v va entre remote y el subcomando (git remote -v).

¿Por qué no set-url --push al fork y fetch al upstream? El man: push y fetch del mismo remote deben ser el mismo lugar. Dos remotes (origin + upstream).

¿--mirror=fetch para “tener todas las ramas”? El man: espeja refs/ y pisa commits locales. Solo en bare. Un agente necesita working tree.

¿fatal: remote origin already exists? GitHub Docs: el nombre está tomado. Exit 3. No lo borres; usa otro nombre o el origin que ya hay.

El curso instalar un agente cubre el loop local. Hub: comparativas y decisiones. Remote no es fetch: nombra el repo; no trae objetos.

Verificado 2026-09-04 contra git-remote(1) (Git 2.50.1 / Apple Git-155; man 2.54.0), git-scm.com/docs/git-remote (HTTP 200) y GitHub Docs “Managing remote repositories” (HTTP 200, /get-started/git-basics/managing-remote-repositories).