Criando nomes melhores para branches de geração com `jj`

• jj é um sistema de controle de versão compatível com Git que recomenda branches anônimas, mas para fazer push para um repositório Git é preciso um bookmark, ou seja, um nome de branch do Git
• O jj git push --change xyz padrão cria a branch push-xyz; como é centrado no change ID, isso é natural na CLI, mas na lista do GitHub fica difícil lembrar o conteúdo do trabalho
• É possível melhorar isso mudando o template git_push_bookmark para transformar a primeira linha da descrição em um slug curto com slugify() e adicionar um change ID curto no final
• jj git push --change ozkspkuyzpwu cria add-note-about-jj-bookmark-templates/ozkspkuyzpwu, mantendo boa legibilidade e também a vinculação à revisão
• Em repositórios compartilhados, é possível adicionar um namespace como ddbeck/ na frente, mas como as regras de nomes de branches do Git são complexas, se o nome gerado não for válido será preciso criar o bookmark manualmente

---

Melhorando os nomes de branch para Git push no jj

• jj (Jujutsu) é um sistema de controle de versão compatível com Git e, por vários motivos, espera e recomenda o uso de branches anônimas
• Ao fazer push para um repositório Git, até branches anônimas precisam de um nome; no jj isso é chamado de bookmark, enquanto no Git é chamado de branch
• jj git push --change xyz envia a revisão com ID xyz para a branch Git push-xyz
• O padrão é natural do ponto de vista de enfatizar o change ID, que o jj CLI mostra e usa com frequência, mas na lista de branches no site do GitHub é difícil lembrar que trabalho era aquele apenas olhando push-xyz

Como mudar a configuração

• Crie um novo template alias slugify() e faça o template git_push_bookmark usá-lo

[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 a primeira linha da descrição da mudança para criar um nome curto no formato de slug e acrescenta um change ID curto no final
• Por exemplo, ao executar jj git push --change ozkspkuyzpwu, será criado add-note-about-jj-bookmark-templates/ozkspkuyzpwu
• Esse nome é mais legível e ao mesmo tempo mantém a conexão com o ID da revisão exibido no jj CLI
• Se você for fazer push para um repositório compartilhado com outras pessoas, pode alterar o template para colocar suas branches sob um namespace separado

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

• Não há garantia de que nomes de branch do Git serão sempre seguros
• As regras para nomes válidos de branch no Git são complexas; se o template gerar um nome inválido, ocorrerá um erro e você terá que criar o bookmark manualmente

[GN⁺]

Opiniões no Lobste.rs

• Estou usando isso muito bem com uma abordagem de inserir e aproveitar metadados na mensagem de commit
  Primeiro, crio um alias trailer_v(key) para extrair facilmente valores de trailer da descrição do commit, e num script de push em nushell monto um rótulo de branch no formato ticket/topic com jj log
  Por exemplo, se a mensagem de commit tiver ticket:TKT-123 e topic:stop-crashing, o script que faz push para o GitHub e abre a página "Create PR" usa esses valores
  Git trailers são bons por serem um armazenamento chave-valor que dá para usar de forma consistente na descrição, mas no momento é um pouco incômodo extrair isso na linguagem revset

• Transformar o nome da branch em slug com base na mensagem de commit ou nas mudanças parece o tipo de tarefa que um LLM local faria com facilidade

  • Não sei se há motivo para usar um LLM. O script simples do texto parece mais leve, provavelmente mais rápido e deve funcionar quase tão bem

• Já tive vários casos de colegas perguntando sobre os nomes de branch gerados automaticamente pelo jj
  Estou pensando em usar uma variação dessa abordagem para branches de commits pontuais

• Para mim, nomes de branch baseados em change-id são perfeitos. Não vejo motivo para mudar
  Isso é só o nome de branch exigido por uma ferramenta horrível de code review, não um título

  • Também estou geralmente satisfeito com os nomes de branch automáticos padrão, mas ao fazer push de um conjunto de mudanças para criar PRs pode ficar confuso saber para qual branch cada PR deve apontar
    Talvez desse para resolver também com uma ferramenta que automatize a criação de PR, mas gosto dessa abordagem por ser simples
  • No $JOB, usar nomes de branch descritivos é a prática comum