Qué es torii en realidad
Git ha ganado. Todo código serio corre sobre él, y el modelo de datos de debajo no es el problema: es la razón de que la cosa haya sobrevivido veinte años. El…
Git ha ganado. Todo código serio corre sobre él, y el modelo de datos de debajo no es el problema: es la razón de que la cosa haya sobrevivido veinte años. El problema es la superficie. Entrar en un proyecto en 2026 sigue empezando con media página de conjuros, y la mitad existen porque un comando se diseñó alrededor de lo que hace la fontanería y no de lo que quiere una persona.
torii es un CLI fino y con opiniones sobre el mismo almacén de objetos, las mismas refs y el mismo protocolo. Tu repositorio sigue siendo un repositorio de Git, tus compañeros no instalan nada, y puedes dejar de usar torii en cualquier momento sin migrar nada.
Una capa, dos superficies
El binario presenta un CLI y una TUI, y ambos llaman a la misma biblioteca. No es un detalle de implementación que puedas ignorar: por eso la TUI no tiene funciones que al CLI le falten, por eso no hay un segundo fichero de configuración, y por eso un arreglo en sync aterriza en los dos a la vez. Una TUI atornillada a un CLI como programa aparte se desincroniza en una sola release; una construida sobre la misma capa de dominio no puede.
Por qué libgit2 tiene agujeros
libgit2 está vendorizado, pero compilado con GIT_HTTPS=0 GIT_SSH=0: sus propios transportes de red quedan fuera. El HTTPS pasa por rustls y el SSH por russh, los dos en Rust puro.
El motivo no es la pureza. Es que los transportes de libgit2 arrastran libcurl, libssh2 y OpenSSL, y esos arrastran perl, pkg-config y un día de compilación que no tenías previsto. Sin ellos, compilar torii desde fuente necesita un compilador de C y nada más, y un binario ya construido no enlaza ninguna biblioteca en tiempo de ejecución. Sobre musl con la feature static corre en Alpine, en scratch y en busybox.
El coste es real y conviene nombrarlo: dos implementaciones de transporte que el mundo no lleva quince años machacando. La validación de push contra Bitbucket, Gitea, Forgejo y Sourcehut sigue siendo cosa verificada por razonamiento y no por una prueba contra un servidor vivo.
Qué significa aquí «pensado para personas»
Significa que el verbo coincide con la intención. torii save -am "msg" es add y commit porque son un solo acto. torii sync es pull y push porque eso es lo que quiere decir «ponerme al día con los demás». torii snapshot existe porque «déjame probar algo y poder deshacerlo» es algo que la gente hace constantemente y Git responde con tres mecanismos que no tienen nada que ver entre sí.
Significa también que la herramienta se niega a ser silenciosamente peligrosa. El escáner de secretos corre antes de cada save. Toda reescritura de historia toma un snapshot antes. save --reset --reset-mode hard es reversible. Nada de eso se puede añadir encima de un cliente: tiene que estar en el camino que el comando ya recorre.
Hacia dónde va
El objetivo a largo plazo no es un Git más bonito. Es un sistema de control de versiones diseñado alrededor de cómo trabaja la gente, con torii como camino de migración para salir de Git cuando haya sitio al que ir. Ese horizonte es largo y se construye en abierto. Hasta entonces, esto es un cliente de Git que intenta no obligarte a memorizar fontanería.