Grit: Reescribiendo Git en Rust con agentes

Artículo original ↗ Discusión en Hacker News ↗

Motivación y objetivos declarados

  • El proyecto es una implementación de Git desde cero en Rust, impulsada en gran medida por “agentes” de LLM.
  • Objetivo central declarado: una biblioteca Git enlazable y reentrante, completa en funciones (especialmente red de conexión/credenciales) para herramientas como GUIs basadas en Git y frontends alternativos de VCS.
  • Se enfatiza que no pretende reemplazar al Git canónico como CLI, sino servir como biblioteca allí donde Git/libgit2/gitoxide son incompletos o no resultan adecuados.

Estado técnico y comparación

  • Se informa que supera ~99,3% de la suite de pruebas upstream de Git; las pruebas restantes se omiten explícitamente (correo electrónico, i18n, importadores SVN/Perforce, algunos bitmap/midx, etc.).
  • El propio autor reconoce que actualmente es más lento, más pesado, menos escalable y probablemente más defectuoso que Git; se dice que el Git canónico es mejor en todos los aspectos salvo en “ser una biblioteca enlazable”.
  • El binario es mucho más grande que el de Git, en gran parte por el ecosistema de Rust (análisis de CLI, dependencias). El subconjunto de biblioteca es más pequeño, pero sigue siendo nada trivial.
  • Se compara repetidamente con gitoxide y libgit2, ambos ya ofrecen bibliotecas pero carecen de paridad completa de funciones/red.

Casos de uso e interés

  • Usos potenciales: redes/credenciales de Git integradas en aplicaciones Rust, servidores/clientes Git personalizados, compilaciones WASM para entornos de navegador/edge.
  • Algunos lo ven como un experimento interesante o una prueba de concepto para el desarrollo “agentic” y los ports asistidos por LLM a gran escala.
  • Otros cuestionan si existe algún nicho práctico más allá de lo que podría lograrse ampliando gitoxide/libgit2.

Coste, ROI y practicidad

  • El gasto en tokens se estima alrededor de $8k–$15k.
  • Muchos comentaristas consideran que el ROI es pobre: una herramienta lenta, incompleta y no probada frente a un Git de eficacia comprobada, con alternativas Rust ya existentes.
  • Algunos argumentan que principalmente demuestra que la IA puede “hacer que pasen las pruebas” sin probar robustez en uso real.

Licencias, copyright y ética

  • Controversia principal: el Git original es GPL; este proyecto se publica bajo MIT.
  • A los agentes LLM se les dio el código fuente y las pruebas de Git como “fuente de verdad”, no solo comportamiento de caja negra. Los críticos lo llaman plagio, “license washing” o “Rustwashing” de una base de código copyleft.
  • Debate legal largo y mixto:
    • Un lado: una reimplementación en Rust con una estructura diferente, más unas métricas de similitud bajas, significa que no es una obra derivada; usar las pruebas GPL como especificación conductual está permitido; la GPL no “infecta” automáticamente implementaciones independientes.
    • El otro lado: alimentar directamente código GPL a un LLM y pedir una implementación funcionalmente equivalente es análogo a traducir/adaptar, así que el resultado debería heredar GPL; el LLM se trata como una herramienta de transformación como un compilador/transpilador, no como un borrador mágico de licencias.
    • Argumentos adicionales sobre si las suites de pruebas pueden volver derivados los resultados, y sobre si las salidas de los LLM son siquiera protegibles por copyright.
  • Éticamente, muchos ven esto como una forma de socavar la intención de la GPL y extraer valor comunitario hacia una licencia permisiva, más amigable para empresas, aunque jurídicamente pudiera ser defendible.

Reescrituras en Rust y uso de LLM

  • Frustración más amplia con la cultura de “reescribir en Rust”, especialmente de proyectos GPL a MIT/Apache.
  • Algunos ven Rust como valioso para la seguridad de memoria en infraestructura crítica (p. ej., Git, nginx); otros sostienen que los principales problemas son de lógica, no de memoria, y que las reescrituras impulsadas por IA pueden introducir errores peores de los que eliminan.
  • Fuerte rechazo al código generado por LLM, “vibecoded” o “slop”, en componentes sensibles a la seguridad.
  • Unos pocos expresan entusiasmo por el enfoque experimental y agentic, y por usar LLM para impulsar ports, pero muchos sienten que la novedad se ha desgastado y que estos proyectos ahora necesitan beneficios claros y visibles para el usuario.

Enfoques alternativos propuestos

  • En lugar de una reescritura total:
    • Ampliar gitoxide o libgit2, especialmente en red/credenciales, posiblemente con asistencia LLM dirigida.
    • Primero extraer y formalizar una especificación conductual a partir del código, pruebas y documentación de Git, y luego reimplementar desde ese “contrato” para evitar trucos con las pruebas y reducir costes.
    • Centrarse en herramientas o abstracciones nuevas sobre el modelo de almacenamiento de Git, en lugar de clonar toda su implementación.