Lançado o jj v0.42.0 - Sistema de controle de versão compatível com Git

• Mudança para o alocador de memória mimalloc, melhorando o desempenho em multithread
• Remoção de opções de comando obsoletas como jj commit --reset-author/--author e jj describe --no-edit/--edit/--reset-author/--author
• Remoção das opções jj git push --allow-new e jj metaedit --update-committer-timestamp
• Remoção de opções de configuração obsoletas como git.auto-local-bookmark e git.push-new-bookmarks
• jj evolog deixa de oferecer suporte a predecessor de commits legados registrados antes do jj 0.30
• O autocompletar do shell agora exibe descrições de aliases personalizados, revset-alias, template-alias e fileset-alias, extraindo a descrição do campo .doc em definições de alias em formato de tabela
• jj show agora aceita várias revisões e, mais próximo de git show, exibe cada revisão em sequência
• jj git fetch agora cria evolution history com base em change ID e, se o remoto preservar o change ID, faz rebase das revisões descendentes locais sobre o pai reescrito
• O comando jj util backend name mostra o nome do backend de commit usado no repositório atual
• Adicionada a configuração edit-invocation-mode para o editor de diff; ao definir "file-by-file", o editor é executado uma vez para cada arquivo alterado, permitindo o uso de ferramentas por arquivo como vimdiff
• jj git remote add agora reporta erro, em vez de panic, quando o nome do remoto está vazio ou contém espaços
• Com a saída colorida desativada, o diff color-words agora mostra before/after em linhas separadas, melhorando a legibilidade de diffs enviados por pipe ou redirecionados

[GN⁺]

Opiniões no Lobste.rs

• Fiquei me perguntando se, agora que jj git fetch gera histórico de evolução baseado em change ID, quando o remoto preserva change IDs, isso significa que não será mais necessário fazer jj new main logo após cada jj git fetch
  Se for isso, parece uma melhoria bem boa de qualidade de vida

  • Não me parece que seja isso. Ao fazer fetch, changes diferentes de antes aparecerão em main, então isso provavelmente não ajuda nessa parte
  • Se você adicionar um trailer na mensagem de commit, qualquer remoto vai preservá-lo
    Só não sei como isso funciona com commits de merge gerados pelo GitHub que não têm change ID

• O que mais me chamou atenção foi a parte sobre a troca para o alocador de memória mimalloc para melhorar o desempenho multithread
  Já usei algo como jemalloc em processos de longa duração para reduzir fragmentação, mas jj me parece o tipo de ferramenta que inicia em 1 ms e termina em menos de 10 ms, então é surpreendente que trocar o alocador faça diferença perceptível
  Fui procurar mais e achei o PR em https://github.com/jj-vcs/jj/pull/9484 e só algo como https://github.com/jj-vcs/jj/issues/2490#issuecomment-2595323515, mas não parece um ganho enorme de velocidade. Ainda assim, se fica mais rápido e a mudança são só algumas linhas, ótimo

• Foi dito “se o remoto preserva change IDs”, mas eu não sei se remotos normalmente preservam isso
  Sei que jj gerrit upload adiciona o footer de change ID, mas o jj git push normal não faz isso

  • Dá para considerar que preserva, desde que o commit não seja reescrito
    Só que operações que reescrevem commits, como squash merge ou rebase merge do GitHub, não preservam. Se for processado por ferramentas padrão baseadas em libgit2, cabeçalhos customizados não são preservados; algumas ferramentas, como a biblioteca Rust usada pelo GitButler, suportam preservar cabeçalhos customizados, mas duvido que os forges usem algo assim
  • Fiquei curioso sobre quais remotos preservam change IDs
    Também não sei como verificar se isso está sendo preservado corretamente
  • Acho que o change ID mencionado aqui não é o change ID do Gerrit, e sim o change ID do jujutsu
    A documentação tem mais detalhes
  • O GitLab preserva. Uso assim na empresa atualmente
    O GitHub também preserva; dá para confirmar olhando commits do pushcx no código-fonte do lobsters ou algum commit meu

• Fiquei curioso se existe algum material bom para ler ou assistir sobre por que usar jj em vez do Git padrão
  Sei que o jj pode funcionar sobre o Git e até testei em projetos pessoais, mas ainda não encontrei aquele argumento decisivo de por que ele seria melhor ou mais fácil