Vejo um futuro no jj

• O novo sistema de controle de versão jj é um projeto escrito em Rust, uma ferramenta com estrutura que complementa as limitações do Git existente e permite adoção gradual
• Com base na experiência anterior de analisar o potencial de crescimento do Rust, o autor avalia que o jj também tem potencial semelhante em termos de adequação ao mercado, equipe especializada e base de usuários
• O jj é compatível com repositórios Git e, ao mesmo tempo, oferece um fluxo de trabalho mais simples, sendo especialmente mais acessível para desenvolvedores que não estão familiarizados com a estrutura interna do Git
• O uso real está se expandindo em empresas como Google e Oxide, e está se formando uma comunidade entusiasmada e uma equipe de desenvolvimento dedicada
• O autor está se juntando à ERSC, que desenvolve uma plataforma de colaboração baseada em jj, e planeja impulsionar diretamente o crescimento do ecossistema jj como nos primeiros tempos do Rust

---

Por que escolhi Rust

• O autor passou a se interessar pela linguagem no Natal de 2012, ao ver no Hacker News a notícia “Rust 0.5 released”
  • Na época, era desenvolvedor Ruby on Rails, mas desde a faculdade tinha interesse em compiladores e programação de sistemas
• Ao avaliar as chances de sucesso do Rust, considerou três fatores: adequação ao mercado, equipe de desenvolvimento e base de usuários
  • Não existia uma linguagem confiável para substituir C/C++, e o Rust apresentou uma abordagem inovadora ao oferecer segurança de memória sem garbage collection
  • Como havia patrocínio da Mozilla e um plano de introduzir Rust no Firefox, ele julgou alta a possibilidade de garantir uma base de uso real
• A atmosfera gentil e colaborativa da comunidade Rust também foi um fator atraente
  • Depois, o autor escreveu o tutorial “Rust for Rubyists” e participou como coautor da documentação oficial

O surgimento do jj

• jj (Jujutsu) não é uma linguagem de programação, mas um novo sistema de controle de versão (VCS) implementado em Rust
  • É compatível com Git e pode ser adotado gradualmente usando os repositórios existentes como estão
• O autor começou a explorar o jj por recomendação da desenvolvedora Rain, que tem gostos técnicos parecidos com os dele
  • Rain veio da equipe de gerenciamento de código-fonte da Meta, e sua recomendação foi recebida como um sinal confiável
• No fim de semana, ele experimentou o jj diretamente e iniciou um projeto de criação de tutorial
  • Assim como quando estudou Rust, abordou o tema organizando os conceitos por meio da escrita
  • Como resultado, o tutorial teve recepção positiva na comunidade

Perspectivas para o futuro do jj

• O autor vê no jj um padrão de crescimento semelhante ao do início do Rust
  • Adequação ao mercado, capacidade da equipe e possibilidade de expansão entre usuários são todos pontos positivos
• Em termos de adequação ao mercado, o Git ainda tem vantagem absoluta, mas o jj consegue trabalhar diretamente com repositórios Git, o que permite adoção parcial
  • Dentro da própria Oxide, o uso começou com Rain e se espalhou a ponto de surgir um canal dedicado, mostrando alto interesse
• O jj também está sendo usado internamente no Google, o que é interpretado como um sinal semelhante ao da adoção do Rust pela Mozilla
  • Mesmo em grandes monorepos do Google (baseados no backend do Piper), alguns projetos já utilizam jj, o que funciona como prova social (social proof)
• Existe uma curva de aprendizado, mas para usuários que não conhecem a fundo a estrutura interna do Git, ele oferece uma usabilidade mais intuitiva e simples
  • Quanto mais especialista em Git a pessoa for, mais precisará se adaptar aos novos conceitos; já desenvolvedores em geral se acostumam rapidamente
• A comunidade do jj está crescendo com uma atmosfera entusiasmada e acolhedora, lembrando a comunidade Rust dos primeiros tempos

Equipe e comunidade do jj

• O criador Martin vem se dedicando ao desenvolvimento do jj há muito tempo e, recentemente, migrou do uso de uma conta pessoal para uma conta oficial da organização, além de organizar a governança
• Os membros da equipe são especialistas com ampla experiência no desenvolvimento de ferramentas de controle de código-fonte, o que fortalece a direção técnica e o controle de qualidade
• A comunidade está crescendo rapidamente por meio de feedback ativo e colaboração, recriando a energia positiva da comunidade Rust inicial

Novo desafio: entrada na ERSC

• O autor decidiu deixar a Oxide e entrar na startup ERSC, que desenvolve uma plataforma de colaboração baseada em jj
  • A Oxide era um excelente lugar para trabalhar, mas o desejo de participar mais profundamente do ecossistema jj foi o fator decisivo
• A ERSC pretende construir uma plataforma de colaboração para desenvolvedores sobre o jj, e o autor menciona o caso do GitHub, que começou com a razão social Logical Awesome, para explicar um estágio inicial semelhante
• O autor planeja encerrar seu trabalho na Oxide, descansar e depois se dedicar às atividades da comunidade jj e à conclusão do tutorial
  • Ele antecipa maior atuação no Discord, série de posts no blog e contribuições para a comunidade
• Ele avalia 2025 como um novo ponto de virada e expressa gratidão por poder se desafiar em um projeto pelo qual sente verdadeira paixão

Conclusão

• O autor está convencido de que o jj tem potencial para reproduzir a trajetória de crescimento do Rust
  • Compatibilidade com Git, possibilidade de adoção gradual, equipe dedicada e comunidade ativa são as bases dessa visão
• O jj mostra potencial para evoluir de uma simples ferramenta para uma plataforma inovadora de colaboração entre desenvolvedores
• A jornada do autor, que começou com Rust, agora segue para um novo capítulo ao lado do jj

[tujuc]

Isso já apareceu várias vezes, mas acho que vale dar uma olhada.

[GN⁺]

Comentários no Hacker News

• Usei o jj seriamente umas duas vezes. O conceito de first-class conflict é legal, mas na prática eu faço staging/commit com muito mais frequência do que resolvo conflitos. Como vim do magit, a divisão e seleção de hunks no jj pareceram muito desconfortáveis. Eu faço rebase com frequência, então já aproveitava a maior parte das vantagens do jj com os atalhos de rebase do magit. Para alguém como eu, o UX de seleção de hunks precisaria melhorar muito para o jj superar o magit

  • A chave no jj é não pensar em staging nem em commit. Tudo é uma mudança(change), e você precisa pensar em marcar um pai ou um ancestral mais distante com um bookmark, fazer squash nela ou mover o bookmark para a próxima mudança
  • Eu também faço rebase com frequência, mas não gosto da filosofia de controle de versão opinativa demais do jj. Especialmente para iniciantes, esconder demais o design interno não ajuda no aprendizado
  • Fiquei curioso sobre como é exatamente o UX de seleção de hunks no magit. Não me pareceu tão diferente do do jj. Usei o GitUp(gitup.co) por muito tempo e, embora o UX do jj não seja totalmente natural, isso parece o tipo de problema que dá para resolver com customização de atalhos
  • Se você entende por que é importante colocar um bom UX em cima do Git, então já entendeu 95% da filosofia do jj
  • Também dá para usar o git index no jj. Só não pode usar comandos do jj que mudem o git_head. Eu uso um alias para commitar mudanças staged (exemplo de config.toml)

• Sempre que vejo uma alternativa ao Git, sinto um pouco de sentimento ludita. Já temos linguagens, frameworks e ferramentas demais. Pelo menos no caso de VCS, acho ótimo existir uma solução quase universal como o Git. O jj até pode resolver problemas, mas considerando o peso de a indústria ter de suportar os dois sistemas, não parece ganho líquido

  • O UI ruim do Git me irrita tanto que eu gostaria que ele fosse substituído. Queria uma ferramenta nova que explicasse melhor os conceitos do Git
  • O jj é uma opção que cada desenvolvedor pode escolher individualmente. Um repo de jj é um superconjunto de um repo git, então as ferramentas existentes não quebram
  • Já trabalhei numa empresa que usava svn, mas primeiro adotou Git com git-svn. O jj parece seguir uma abordagem parecida. Mesmo sem conhecer jj, o CI e as ferramentas existentes continuam funcionando
  • O Git é um fator de perda de produtividade e, na era da programação baseada em agentes, isso é um problema ainda maior. Não acho que o jj seja inovador o bastante. Preferiria um novo VCS que rastreasse mudanças em nível atômico(atomic). Numa estrutura assim, o conceito de branch desapareceria, e o estado do repositório poderia ser composto por planos(plan) e átomos(atom). Mas migrar para um sistema desses seria um desafio enorme
  • Assim como vieram rcs, cvs, svn e depois git, o git também será substituído por algo melhor um dia

• Já usei jj, mas estou acostumado ao Sublime Merge. Fazer controle de versão pela CLI exige muita digitação repetitiva e é fácil perder o estado. Na GUI, o estado está sempre visível e dá para abrir o diff ou digitar a mensagem de commit com um clique. Não quero nunca mais selecionar hunks pelo teclado. O SM é muito confortável. Seria ótimo se surgisse um bom GUI para jj ou se o SM integrasse jj

• A verdadeira notícia é que as pessoas começaram a criar coisas como “jjhub” (ersc.io)

  • Acho que ‘jjhub’ é um bom primeiro passo. Já dá para usar jj com github hoje, mas ele precisa oferecer algo valioso além disso
  • Como referência, tem isto também: post do blog sobre Stacking
  • O Gerrit também combina bem com os conceitos do jj, e um RFC para adicionar suporte a Jujutsu change ID foi aprovado
  • O nome jjhub é bem legal
  • Espero sinceramente que dê certo. Já passou da hora de surgir uma alternativa de verdade ao Github

• Dizem que o jj está se espalhando dentro do Google, mas o Google tem a tendência de trocar seu VCS interno periodicamente. Em 7 anos, já mudou de git wrapper para uma extensão de mercurial, e agora para jj

  • Na verdade, a maioria das ferramentas internas do Google dura pouco. Mesmo assim, o jj é inovador por manter a identidade(identity) da mudança. No git, depois de um rebase ou amend, vira um commit totalmente diferente; no jj, a mesma mudança continua sendo rastreada. Ainda assim, é bem provável que o jj continue usando o git como backend de armazenamento
  • Espero que o jj continue existindo. Quero usar o mesmo fluxo de trabalho em casa e no trabalho. É muito mais rápido que mercurial
  • Desta vez, parece que a intenção é aposentar também o fork de Perforce. Visto de fora, é mudança demais
  • O git wrapper originalmente era experimental, e o sistema baseado em mercurial foi mantido por quase 10 anos

• Fico curioso se o jj lida melhor com arquivos binários grandes do que o git. No desenvolvimento de jogos, o Perforce ainda reina. Mesmo com LFS, o git não basta

  • O suporte a binários do Perforce é, na prática, igual ao Git LFS. A diferença é mais a questão de suporte corporativo
  • O jj usa git como repositório e não oferece suporte a LFS, então tem as mesmas limitações do git nesse ponto
  • Por enquanto não há nenhuma melhora especial, mas esse tema é conhecido e pode haver mudanças no futuro

• Passei um dia seguindo o tutorial do Jujutsu e gostei bastante. Ainda assim, parecia que havia uma peça faltando no quebra-cabeça. Por exemplo, fiquei me perguntando se o change id realmente ajuda na hora de abrir um PR no GitHub. Talvez ele só mostre seu valor de verdade com o backend Piper interno do Google. Fico curioso sobre os planos da ERSC. Pessoalmente, eu gostaria de um fluxo de trabalho distribuído com code review offline embutido

  • Fico feliz que tenha sido divertido de usar :) No GitHub, hoje, quase não há vantagem no change id. Mas dá para ter parte dessa experiência com ferramentas como jj-spr. Também houve um tweet em que o SVP do GitHub demonstrou interesse no jj. Além disso, usei beads, um sistema que coloca issues dentro do repositório, e gostei bastante
  • Commits criados com jj incluem um cabeçalho change-id, então, mesmo que o GitHub não conheça jj, usuários de jj ainda conseguem rastrear rebases entre si. Dá para verificar com git cat-file -p HEAD

• Usei jj por 1 ou 2 meses em projetos pessoais e estou bem satisfeito. Mas, ao editar revisões antigas, arquivos adicionados recentemente ao .gitignore podem acabar entrando por engano. Fora isso, é bom. Mesmo assim, ainda tenho muito mais conhecimento de Git, então vou introduzi-lo no trabalho aos poucos

• Entrei este ano na empresa do Sapling/Subversion e ainda não usei jj. Mesmo assim, o Sapling parece muito mais intuitivo, e pilhas de commits são mais fáceis de entender do que branches. Só fico curioso para saber como seria sem o suporte de algo como a UI de review da Meta. Esse tipo de projeto é muito necessário

  • Isso, Sapling e jj são projetos irmãos na mesma direção

• Seja qual for o nome, East River Source Control é um nome muito bom mesmo