Lançado o jj v0.43.0

• O sistema de controle de versão compatível com Git jj v0.43.0 adiciona o jj run, que executa comandos sobre vários conjuntos de mudanças, permitindo automatizar melhor tarefas repetitivas de verificação e correção
• O jj run usa uma working copy dedicada para cada conjunto de mudanças e também propaga alterações e conflitos gerados por comandos que modificam a working copy, como cargo check ou cargo fix
• Esta versão inclui mudanças que afetam configurações existentes e a forma de usar revsets, como git_head(), git_refs(), resolução de símbolos no estilo Git e a remoção de ui.revsets-use-glob-by-default
• Também foram adicionados jj show --reversed, busca de configuração em /etc/jj, jj config gc, jj gerrit upload -o, a função de revset forks() e o estilo de texto tachado
• Foram corrigidos problemas no tratamento de identity de arquivos no Windows, snapshots de working copy imutável, aviso de URL remota duplicada e corrupção de loose Git objects em Intel Raptor Lake e aarch64

---

Visão geral da versão

• jj é um sistema de controle de versão compatível com Git, simples e poderoso
• Na v0.43.0, foi adicionado o novo jj run, que aplica comandos a vários conjuntos de mudanças
• As instruções para começar estão em installation instructions

Executar comandos por conjunto de mudanças: jj run

• O jj run permite executar o mesmo comando sobre vários conjuntos de mudanças
• Cada conjunto de mudanças usa sua própria working copy dedicada e isolada
• O comando executado pode atualizar a working copy, e as mudanças e conflitos gerados como resultado são propagados de forma apropriada
• Exemplos de uso:
  • jj run -- cargo check --all-features
  • jj run -- cargo fix

Remoções que afetam compatibilidade

• As funções git_head() e git_refs(), que já estavam obsoletas em revsets e templates, foram removidas
• Símbolos no estilo Git, como refs/heads/main, não são mais resolvidos como revisões
  • Em vez disso, deve-se usar a sintaxe <name> ou <name>@<remote> para bookmark/tag
• A opção obsoleta ui.revsets-use-glob-by-default também foi removida
• jj bookmark track e untrack não suportam mais o padrão <kind>:<bookmark>@<remote>
  • A sintaxe simbólica <bookmark>@<remote> continua sendo suportada
  • Issue relacionada: #9226

Novos recursos adicionados

• jj show agora suporta a flag --reversed
• O jj agora também procura arquivos de configuração em /etc/jj
• jj config gc limpa configurações de repositórios apagados ou movidos na pasta ~/.config/jj/repos
  • Issue relacionada: #9362
• jj gerrit upload agora suporta as flags -o / --option, funcionando como git push -o ou --push-option
• jj git fetch faz rebase de revisões descendentes de revisões reescritas com base no change ID
  • Antes, quando havia várias revisões com bookmark em uma stack, a revisão reescrita e suas descendentes nem sempre eram rebased
  • Revisões descendentes imutáveis não são rebased
• Foi adicionada a função de revset forks()
  • Ela retorna todos os commits com dois ou mais filhos
• A configuração colors agora suporta estilo de texto tachado com { crossed-out = true }

Problemas corrigidos

• No Windows, ao consultar a identity de arquivo de um caminho, links simbólicos não são mais seguidos
  • Isso alinha o comportamento ao Unix
  • Antes, dois links simbólicos apontando para o mesmo destino eram tratados como o mesmo arquivo
  • Essa verificação de identity é usada para detectar aliases dos diretórios reservados .git e .jj ao gravar a working copy
  • Issue relacionada: #8924
• Quando a working copy estava em estado imutável, o jj agora cria uma nova revisão de working copy durante o snapshot
  • Antes, a nova revisão era criada logo após a working copy se tornar imutável
  • Issues relacionadas: #7751, #9338
• jj git remote add agora emite um aviso se a fetch URL ou a effective push URL do novo remote for exatamente igual à de um remote existente
  • Issue relacionada: #413
• Foi corrigido o problema de loose Git objects corrompidos em CPUs Intel Raptor Lake e em aarch64
  • Antes, o jj informava sucesso no commit, mas depois o git fsck podia falhar com incorrect data check, corrupt loose object e missing blob
  • Operações posteriores do jj também podiam falhar com corrupt deflate stream

[GN⁺]

Comentários no Lobste.rs

• Estou bem empolgado com jj run

• Fico contente que a descontinuação tenha sido revertida em jj bookmark track/untrack <name>@<remote>
  Ter que digitar --remote toda vez sempre foi meio ruim

• A parte sobre terem corrigido objetos loose do Git corrompidos em Intel Raptor Lake CPU e aarch64 parece um bug interessante
  Gostaria de ler um post de blog relacionado, se sair 😃

• Até agora eu achava que todos os objetos Git corrompidos que eu tinha visto eram culpa de rollback do sistema de arquivos
  Depois de um desligamento forçado, o rollback do f2fs costumava criar estados de disco bem interessantes; é muito interessante descobrir que havia corrupção simplesmente daquele lado

• Estou curioso para saber como jj run difere de jj fix
  Até no exemplo do changelog eles executavam cargo fix com jj run, então os dois claramente parecem se sobrepor

  • jj run cria uma cópia de trabalho inteira e executa o comando dentro dela
    jj fix passa o conteúdo de um único arquivo para o comando via pipe e usa a saída como o novo conteúdo desse arquivo
    Se a ferramenta se encaixa bem com jj fix, geralmente algo como um formatador ou linter, ele é muito mais rápido, mas jj run é mais flexível
  • Pelo que entendi, run executa um comando para cada alteração, e fix aplica um filtro a cada arquivo alterado
    No meu caso, seria algo como rodar a suíte de testes com run para verificar se cada commit é válido e, depois, rodar um formatador nos arquivos com fix
    Ainda não atualizei, então isso é só a minha interpretação

• Vou brincar um pouco com jj run, mas acho bem provável que ele fique mais complicado do que deveria por causa da forma como uso direnv