jj init – poniéndose en serio con reemplazar Git con Jujutsu

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

Una nueva herramienta de control de versiones llamada Jujutsu (“jj”) pretende reemplazar el flujo de trabajo visible para el usuario de Git sin dejar de ser compatible con los repositorios Git existentes. Los comentaristas se sienten intrigados por el modelo de jj en el que la copia de trabajo siempre es un commit, su manejo simplificado de la edición del historial y de los cambios apilados, y sus posibles ventajas para flujos de trabajo grandes o complejos; pero muchos son escépticos por la pérdida del índice de Git, temen una complejidad conceptual añadida y cuestionan si los desarrolladores no deberían simplemente aprender el modelo subyacente de Git. En general, la gente ve potencial en jj para mejorar la ergonomía y las herramientas, pero duda de que pueda superar el dominio de Git o escapar por completo de su complejidad subyacente.

Recepción general de Jujutsu (jj)

  • Varios comentaristas se sienten intrigados por jj y planean probarlo, especialmente quienes ya están frustrados con la interfaz de Git.
  • Algunas personas que se han cambiado informan fricción inicial, sobre todo por el modelo de “la copia de trabajo es un commit”, pero dicen que una vez que “hace clic”, Git entonces se siente torpe.
  • Otros son escépticos y ven jj como una capa de complejidad sobre Git en lugar de una verdadera simplificación del control de versiones.

La copia de trabajo como un commit y la ausencia de índice

  • El modelo de jj: todos los cambios forman siempre parte de un commit; no existe un “índice” expuesto ni un estado sin stage.
  • Quienes lo apoyan argumentan que esto reduce los estados conceptuales y hace que operaciones como dividir commits sean más fáciles y menos propensas a errores.
  • Quienes lo critican prefieren el flujo de Git en dos pasos de “add y luego commit”, diciendo que fomenta agrupar deliberadamente cambios relacionados y evita auto-confirmar todo.
  • Hay cierta confusión sobre si jj conserva de manera significativa un comportamiento similar al índice; un comentarista aclara que, en la práctica, confirma todos los cambios por defecto.

División de commits y flujos de trabajo

  • El comando split de jj se discute mucho.
  • Sus fans dicen que reduce drásticamente la fricción para dividir commits retroactivamente y reorganizar el historial en comparación con los rebases de varios pasos de Git.
  • Sus detractores encuentran que el flujo de trabajo de jj split es poco intuitivo (por ejemplo, qué parte se considera “primera” frente a “segunda”) y sostienen que dividir commits es demasiado importante como para que sea “raro”.

Complejidad de Git, modelos mentales y carga de aprendizaje

  • Muchos comentarios lamentan los conceptos confusos de Git (detached HEAD, reflog, semántica de merge en rebase, inversión de ours/theirs) y la frecuencia de los “footguns”.
  • Otros defienden Git como potente pero no excesivamente difícil si internalizas su modelo central; sostienen que los desarrolladores deberían aprender las herramientas más a fondo, comparándolo con entender bases de datos o redes.
  • Hay desacuerdo sobre si “necesitar entender internals” es razonable para el uso cotidiano.

Herramientas, GUIs y repositorios grandes

  • Varias personas subrayan la importancia de buenas GUIs (para staging, selección de hunks, bisect, reflog) y dicen que el VCS de próxima generación debería ser primero GUI.
  • Algunos señalan que jj actualmente carece de soporte GUI maduro, lo que debilita flujos de trabajo que dependen mucho de la experiencia de stage similar a la del índice.
  • Para repositorios grandes, se menciona watchman como una forma de mejorar el rendimiento de jj, pero en general el comportamiento en repos grandes se discute poco y sigue siendo algo poco claro.

Puntos meta: nombre, ecosistema y longevidad

  • Surgen preocupaciones sobre que el nombre binario jj entre en conflicto con enlaces de teclas comunes de Vim.
  • A algunos les preocupa la longevidad de jj por su asociación con trabajo financiado por Google, mientras que otros aclaran que no es un fork de Git y que simplemente usa libgit.
  • Unos pocos sugieren que lo que más hace falta no es un nuevo VCS, sino una interfaz o frontend más sensatos y compatibles con Git.