Lanzamiento de jj v0.42.0 - sistema de control de versiones compatible con Git

• Cambio al asignador de memoria mimalloc para mejorar el rendimiento multihilo
• Eliminación de las opciones de comando en desuso jj commit --reset-author/--author, jj describe --no-edit/--edit/--reset-author/--author, entre otras
• Eliminación de las opciones jj git push --allow-new y jj metaedit --update-committer-timestamp
• Eliminación de las opciones de configuración en desuso como git.auto-local-bookmark y git.push-new-bookmarks
• jj evolog deja de dar soporte a los predecesores de commits heredados registrados antes de jj 0.30
• El autocompletado del shell muestra descripciones de alias personalizados, revset-alias, template-alias y fileset-alias, y extrae las descripciones del campo .doc en definiciones de alias tipo tabla
• jj show ahora acepta varias revisiones y muestra cada una en orden, más parecido a git show
• jj git fetch crea evolution history basada en change ID, y si el remoto conserva el change ID, hace rebase de las revisiones descendientes locales sobre el padre reescrito
• El comando jj util backend name muestra el nombre del backend de commits usado en el repositorio actual
• Se agrega la configuración edit-invocation-mode para el editor de diff; al indicar "file-by-file", ejecuta el editor una vez por cada archivo modificado, permitiendo usar herramientas por archivo como vimdiff
• jj git remote add ahora informa un error en lugar de provocar un panic cuando el nombre del remoto está vacío o contiene espacios
• El diff color-words con la salida de color desactivada muestra before/after en líneas separadas, mejorando la legibilidad de diffs enviados por pipe o redirigidos

[GN⁺]

Opiniones en Lobste.rs

• Me pregunto si, ahora que jj git fetch genera un historial de evolución basado en change ID, si el remoto preserva los change ID ya no haría falta ejecutar jj new main justo después de cada jj git fetch
  Si es así, parece una mejora bastante buena en calidad de vida

  • No me suena a que diga eso. Si haces fetch, aparecerán cambios distintos a los anteriores en main, así que no parece que ayude con esa parte
  • Si agregas un trailer al mensaje del commit, cualquier remoto lo preserva
    Aunque no sé qué pasa con los commits de merge creados por GitHub que no tienen change ID

• Me da más curiosidad la parte de que cambiaron al asignador de memoria mimalloc para mejorar el rendimiento multihilo
  En procesos de larga duración sí he usado cosas como jemalloc para mitigar la fragmentación, pero jj se siente como algo que arranca en 1 ms y termina en menos de 10 ms, así que me sorprende que cambiar el asignador se note
  Busqué un poco más y el PR es https://github.com/jj-vcs/jj/pull/9484, y solo encontré algo como https://github.com/jj-vcs/jj/issues/2490#issuecomment-2595323515, pero no parece una gran mejora de velocidad. Aun así, si queda más rápido y el cambio son solo unas cuantas líneas, está bien

• Dijeron “si el remoto preserva los change ID”, pero normalmente no sé si los remotos hacen eso
  Sé que jj gerrit upload agrega el footer de change ID, pero jj git push normal no lo hace

  • Se puede asumir que se preservan mientras el commit no sea reescrito
    Pero operaciones que reescriben commits, como el squash merge o el rebase merge de GitHub, no los preservan. Si se procesa con herramientas estándar basadas en libgit2, los encabezados personalizados no se conservan, y algunas herramientas como la biblioteca de Rust que usa GitButler sí admiten preservar encabezados personalizados, pero no está claro si los forges usan algo así
  • Me pregunto qué remotos preservan los change ID
    Tampoco sé cómo verificar si realmente se están preservando correctamente
  • Parece que aquí “change ID” no se refiere al change ID de Gerrit, sino al change ID de jujutsu
    La documentación tiene más información
  • GitLab sí los preserva. En mi trabajo los usamos así ahora mismo
    GitHub también los preserva; se puede comprobar viendo el commit de pushcx en el código de lobsters o mis commits

• Me pregunto si hay algo para leer o ver sobre por qué usar jj en lugar de Git estándar
  Sé que jj puede funcionar sobre Git y hasta lo he probado en proyectos personales, pero todavía no encuentro ese punto decisivo de por qué sería mejor o más fácil