jj init – ficando sério sobre substituir o Git com Jujutsu

Artigo original ↗ Discussão no Hacker News ↗

Uma nova ferramenta de controle de versão chamada Jujutsu (“jj”) tenta substituir o fluxo de trabalho do Git voltado ao usuário, mantendo compatibilidade com repositórios Git existentes. Os comentaristas estão intrigados com o modelo do jj, em que a working copy é sempre um commit, sua forma simplificada de editar histórico e trabalhar com mudanças empilhadas, e possíveis vantagens para fluxos grandes ou complexos — mas muitos são céticos quanto à perda do index do Git, preocupam-se com complexidade conceitual adicional e questionam se os desenvolvedores não deveriam simplesmente aprender melhor o modelo subjacente do Git. No geral, as pessoas veem potencial no jj para melhorar ergonomia e ferramentas, mas duvidam que ele consiga superar a dominância do Git ou escapar totalmente da complexidade subjacente do Git.

Recepção geral do Jujutsu (jj)

  • Vários comentaristas estão intrigados com o jj e planejam experimentá-lo, especialmente aqueles já frustrados com a UI do Git.
  • Algumas pessoas que fizeram a troca relatam atrito inicial, principalmente por causa do modelo de “working copy é um commit”, mas dizem que, quando isso “clica”, o Git passa a parecer desajeitado.
  • Outros são céticos, vendo o jj como algo que adiciona complexidade em cima do Git, em vez de realmente simplificar o controle de versão.

Working copy como um commit e ausência de index

  • O modelo do jj: todas as alterações estão sempre parte de um commit; não existe um “index” exposto nem estado não staged.
  • Os defensores argumentam que isso reduz estados conceituais e torna operações como dividir commits mais fáceis e menos propensas a erro.
  • Os críticos preferem o “add depois commit” em duas etapas do Git, dizendo que isso incentiva agrupar deliberadamente mudanças relacionadas e evita fazer auto-commit de tudo.
  • Há alguma confusão sobre se o jj preserva de forma significativa um comportamento semelhante ao index; um comentarista esclarece que ele efetivamente commita todas as mudanças por padrão.

Divisão de commits e fluxos de trabalho

  • O comando split do jj é amplamente discutido.
  • Fãs dizem que ele reduz drasticamente o atrito para dividir commits retroativamente e reorganizar o histórico em comparação com os rebases em várias etapas do Git.
  • Os detratores acham o fluxo de trabalho do jj split pouco intuitivo (por exemplo, qual parte é considerada “primeira” versus “segunda”) e argumentam que dividir commits é importante demais para ficar “estranho”.

Complexidade do Git, modelos mentais e custo de aprendizado

  • Muitos comentários lamentam os conceitos confusos do Git (detached HEAD, reflog, semântica de merge do rebase, inversão de ours/theirs) e a frequência de “footguns”.
  • Outros defendem o Git como poderoso, mas não excessivamente difícil se você internalizar seu modelo central; eles argumentam que desenvolvedores deveriam aprender ferramentas mais profundamente, comparando isso a entender bancos de dados ou redes.
  • Há desacordo sobre se “precisar entender os internals” é razoável para o uso cotidiano.

Ferramentas, GUIs e grandes repositórios

  • Várias pessoas enfatizam a importância de boas GUIs (para staging, seleção de hunks, bisect, reflog) e dizem que um VCS de nova geração deveria ser GUI-first.
  • Alguns observam que o jj atualmente carece de suporte GUI maduro, o que enfraquece fluxos de trabalho que dependem fortemente da experiência de staging semelhante ao index.
  • Para repositórios grandes, o watchman é mencionado como uma forma de melhorar o desempenho do jj, mas o comportamento em grandes repos ainda é pouco discutido e um tanto अस्पष्ट.

Pontos meta: nome, ecossistema e longevidade

  • Surgem preocupações sobre o nome binário jj conflitar com atalhos comuns do Vim.
  • Alguns se preocupam com a longevidade do jj por causa da associação com trabalho financiado pelo Google, enquanto outros esclarecem que ele não é um fork do Git e simplesmente usa libgit.
  • Alguns sugerem que o que mais se precisa não é um novo VCS, mas sim uma interface ou frontend mais sensata e compatível com Git.