Origin reacende o debate sobre o que vem depois do Git

O que muda no desenvolvimento

A East River Source Control (ERSC) afirma que construir software é colaborativo e que armazenar código com segurança, gerenciar mudanças e garantir disponibilidade são funções críticas. O espaço de controle de versão passou por CVS, SVN e Git, mas o Git se tornou dominante por efeitos de rede.

A ascensão do desenvolvimento agêntico, segundo a ERSC, mudou a escala: equipes produzem mais código mais rapidamente, repositórios crescem, branches ativas aumentam e há contenção na integração de novo trabalho. Agentes se beneficiam de monorepos porque acessam mais contexto com mais facilidade, o que exacerba esses problemas. Eles também levam ambientes de desenvolvimento para a nuvem, com ambientes isolados, exigindo clones rápidos. Problemas antes restritos a grandes organizações estão chegando às demais. A ERSC acredita que, conforme as organizações ampliam ambições, precisarão de uma ferramenta de VCS de próxima geração, mas reconhece que o setor é conservador e que mudanças trazem riscos; por isso, diz construir uma ponte entre o presente e o futuro.

Armazenamento como fundação

A empresa descreve hosts Git típicos: o cliente Git se conecta por protocolo Git a uma camada de serviço que acessa repositórios Git em disco. Na ERSC, a arquitetura mantém cliente e protocolo Git, mas usa uma ponte Git para um motor de armazenamento não-Git.

O argumento central é que o Git não é o futuro do controle de versão. Ele teria sido projetado para as restrições de 2005, não de 2025 ou 2035, e para o kernel Linux, um projeto de código aberto. Isso o deixaria sem recursos importantes para organizações que não compartilham o código com todos. O kernel Linux, embora grande, tem cerca de 43 milhões de linhas, enquanto grandes empresas já tinham monorepos de bilhões de linhas anos atrás; nessa escala, as escolhas importam. Trocar de sistema é difícil porque o Git está integrado a ferramentas e à cultura, como em GitOps. Por isso, a ERSC fala o protocolo Git enquanto muda o armazenamento. A empresa afirma que seu sistema escala horizontalmente, diferente de sistemas que usam o repositório Git como fonte da verdade, e que implantações separadas isolam o uso de outras empresas, dando confiabilidade e controle.

Adoção e Jujutsu

A estratégia de falar o protocolo permite falar múltiplos protocolos. A ERSC diz ser fã do Jujutsu (jj), um sistema de controle de versão com adoção incremental e capacidade de conversar com diferentes backends. A maioria usa jj com backend Git local, e o Google tem um backend para seu sistema Piper; isso permite adotar jj no trabalho mesmo que colegas usem Git, pois para o servidor é só mais um usuário do protocolo Git. A ERSC pretende espelhar isso no servidor: manter o protocolo Git e, no futuro, oferecer um protocolo nativo, ambos sobre o mesmo motor de armazenamento. O caminho seria começar com Git, adotar jj no ritmo individual e, depois, usar o protocolo nativo sobre o mesmo motor.

A empresa ressalva que isso é trabalho futuro, não disponível. Não existe hoje um protocolo nativo do jj no upstream, e a ERSC não afirma que é isso que está construindo. Se for útil e desejado pelo upstream, diz que trabalhará com a comunidade; o protocolo será documentado e modificações de cliente para suportá-lo serão abertas. A ERSC não assume que o upstream queira adotá-lo, já que o protocolo Git atende a maioria dos usuários, e se compromete a ser um bom participante do ecossistema jj.

Próximos passos

O armazenamento é apenas uma parte da colaboração em código; revisão, CI e rastreamento de issues completam o quadro. Enquanto forges tradicionais oferecem tudo em um pacote, a ERSC aposta em customização e produtos como blocos, não uma única forge. O armazenamento vem primeiro, mas a intenção é fazer a solução funcionar com o restante do stack, permitindo trazer software próprio ou adotar partes dos produtos da empresa. Nada está disponível ainda; a empresa diz que abrirá as portas em breve e menciona o JJ Con na semana seguinte.