Crear mejores nombres de ramas de generación con `jj`

• jj es un sistema de control de versiones compatible con Git que recomienda ramas anónimas, pero para hacer push a un repositorio Git se necesita un bookmark, es decir, un nombre de rama de Git
• El valor predeterminado jj git push --change xyz crea la rama push-xyz, y como está centrado en el change ID resulta natural en la CLI, pero en la lista de GitHub es difícil recordar qué trabajo contiene
• Se puede mejorar cambiando la plantilla git_push_bookmark para convertir la primera línea de la descripción en un slug corto con slugify() y añadir después un change ID corto
• jj git push --change ozkspkuyzpwu crea add-note-about-jj-bookmark-templates/ozkspkuyzpwu, manteniendo tanto la legibilidad como la conexión con la revisión
• En repositorios compartidos se puede anteponer un namespace como ddbeck/, pero como las reglas para los nombres de ramas en Git son complejas, si no es válido habrá que crear el bookmark manualmente

---

Mejorar el nombre de rama para Git push en jj

• jj(Jujutsu) es un sistema de control de versiones compatible con Git y, por varias razones, espera y recomienda el uso de ramas anónimas
• Al hacer push a un repositorio Git, incluso una rama anónima necesita un nombre; en jj se llama bookmark y en Git se llama branch
• jj git push --change xyz hace push de la revisión con ID xyz a la rama de Git push-xyz
• El valor predeterminado es natural porque resalta el change ID que la CLI de jj muestra y usa con frecuencia, pero en la lista de ramas del sitio web de GitHub es difícil recordar qué trabajo corresponde a push-xyz

Cómo cambiar la configuración

• Se crea un nuevo template alias slugify() y se modifica la plantilla git_push_bookmark para que lo use

[template-aliases]
"slugify(str)" = '''
truncate_end(
65,
str.first_line()
.replace(regex:'[^[[:alnum:]].]', '-')
.replace(regex:'-{2,}', '-')
.replace(regex:'\.{2,}', '.')
.replace(regex:'(^-+|-+$)', '')
.lower()
)
'''
[templates]
git_push_bookmark = 'slugify(description) ++ "/" ++ change_id.short()'

• slugify() usa la primera línea de la descripción del cambio para crear un nombre corto con formato de slug, y al final añade el change ID corto
• Por ejemplo, si se ejecuta jj git push --change ozkspkuyzpwu, se crea add-note-about-jj-bookmark-templates/ozkspkuyzpwu
• Este nombre es más legible y al mismo tiempo mantiene la conexión con el ID de revisión que se muestra en la CLI de jj
• Si vas a hacer push a un repositorio compartido con otras personas, puedes cambiar la plantilla para colocar tus ramas bajo un namespace separado

[templates]
git_push_bookmark = '"ddbeck/" ++ slugify(description) ++ "/" ++ change_id.short()'

• No se puede garantizar que el nombre de rama de Git siempre sea seguro
• Las reglas para nombres de ramas válidos en Git son complejas; si la plantilla genera un nombre no válido, se producirá un error y tendrás que crear el bookmark manualmente

[GN⁺]

Comentarios de Lobste.rs

• Lo he estado usando bastante bien con una forma de incluir y aprovechar metadatos en el mensaje del commit
  Primero se crea un alias trailer_v(key) para sacar fácilmente valores de trailers de la descripción del commit, y en un script de push de nushell se arma una etiqueta de rama con formato ticket/topic usando jj log
  Por ejemplo, si en el mensaje del commit dejas ticket:TKT-123 y topic:stop-crashing, el script que hace push a GitHub y abre la página de "Create PR" toma esos valores y los usa
  Los Git trailers son buenos como un almacén de clave-valor que puede usarse de forma consistente dentro de la descripción, pero actualmente es un poco incómodo extraerlos en el lenguaje revset

• Convertir en slug nombres de ramas a partir del mensaje del commit o de los cambios se siente como un área que un LLM local podría manejar fácilmente

  • No estoy seguro de que haya una razón para usar un LLM. El script simple del artículo parece más ligero, probablemente más rápido, y seguramente funcionaría casi igual de bien

• Varias veces algún compañero del equipo preguntó por los nombres de rama generados automáticamente por jj
  Estoy pensando en usar una variante de este enfoque para ramas de commits de una sola vez

• Un nombre de rama basado en change-id me parece perfecto. No querría cambiarlo
  Esto solo es el nombre de rama que exige una horrible herramienta de revisión de código, no es un título

  • En general también estoy conforme con los nombres de rama generados automáticamente por defecto, pero cuando empujas varios grupos de cambios para convertirlos en PRs sí puede volverse confuso saber a qué rama debe apuntar cada PR
    Eso también podría resolverse con una herramienta que automatice la creación de PRs, pero este enfoque está bueno por lo simple
  • En $JOB es costumbre usar nombres de rama descriptivos