Un push, tres plataformas

Mantener un repositorio en más de una plataforma suele ser una tarea hecha de alias de shell: un remoto por host, un bucle que empuja a cada uno, y una nota mental sobre cuál vigila de verdad la CI. torii lo modela.

Primario y réplicas

torii mirror add gitlab user paskidev gitorii --primary
torii mirror add github user paskidev gitorii
torii mirror add codeberg user paskidev gitorii
torii mirror sync

Uno de ellos es el primario. No es una etiqueta: decide con qué plataforma hablan torii pipeline, torii issue y torii release cuando no lo dices tú. Las réplicas son copias de la historia y nada más. torii mirror promote github user intercambia cuál es cuál, para el día en que el primario se cae o te mudas de casa.

Cada remoto conserva sus credenciales

Un mirror no replica tus tokens. Cada host tiene su propia entrada en auth.toml, sus propios permisos y su propia caducidad. Importa más de lo que parece: un token que puede empujar a tu réplica no necesariamente puede abrir una pull request en tu primario, y torii te dice cuál falta en vez de fallar con un 403 sin contexto.

Qué pasa cuando uno rechaza

mirror sync empuja a cada remoto por turno. Una réplica que rechaza —una rama protegida, un token caducado, un host caído— no deshace los pushes que ya salieron bien. Aquí no hay transacción distribuida, y fingir que la hay sería peor: tendrías un «ha fallado» que oculta que dos de tus tres remotos van ya por delante.

La salida nombra cada remoto y qué le ha pasado. Arregla el que falló y vuelve a lanzarlo; los que salieron bien no hacen nada la segunda vez.

Autofetch

torii mirror autofetch --enable --interval 30m
torii mirror autofetch --status

Trae del primario en segundo plano para que torii status te diga la verdad sobre cuánto vas por detrás sin tener que ir a preguntar primero.

Cuándo usarlo y cuándo no

Los mirrors son para el mismo repositorio viviendo en varios sitios: un proyecto libre que quiere presencia en Codeberg, una empresa que se muda de plataforma durante seis meses, un proyecto que quiere una copia fuera de una jurisdicción. No sustituyen a una copia de seguridad —tres copias de un force-push son tres historias rotas— y no sirven para repartir trabajo entre plataformas, porque hay exactamente una historia y todos los remotos se la llevan entera.