O futuro do controle de versão

• Manyana é um protótipo de controle de versão baseado em CRDT desenvolvido por Bram Cohen, propondo uma nova abordagem que elimina conflitos de merge e preserva o histórico de forma estrutural
• Usando CRDT (Conflict-Free Replicated Data Type), o merge sempre tem sucesso, e os conflitos são tratados apenas como indicações informativas, permitindo que o usuário reconheça claramente as mudanças
• Seus pontos centrais são persistência da ordem das linhas, merge não bloqueante e histórico incorporado, sem destruir os registros existentes mesmo durante o processo de rebase
• É uma implementação em nível de demonstração escrita em cerca de 470 linhas de código Python, com todo o código e a documentação de design publicados em domínio público no GitHub
• Um caso experimental que apresenta um modelo de controle de versão de próxima geração sem falhas de merge, indo além das limitações do Git

---

Manyana: uma visão coerente para o futuro do controle de versão

• Manyana é um protótipo de sistema de controle de versão baseado em CRDT publicado por Bram Cohen, uma tentativa de resolver o problema de conflitos de merge dos sistemas existentes
• CRDT garante que o merge sempre seja bem-sucedido e trata os conflitos como marcações informativas, permitindo que o usuário veja com clareza quais mudanças realmente aconteceram
• Essa abordagem tem três características principais: persistência da ordem das linhas, tratamento não bloqueante de conflitos e histórico incorporado à estrutura
• Mesmo no processo de rebase, o histórico existente é mantido, e estruturas de merge complexas sem um único ancestral comum também podem ser tratadas de forma estável
• Manyana é uma implementação de demonstração escrita em cerca de 470 linhas de código Python, com a documentação de design e o código publicados em domínio público no GitHub

O núcleo da abordagem baseada em CRDT

• CRDT oferece eventual consistency, garantindo que o merge sempre tenha sucesso e produza o mesmo resultado independentemente da ordem do merge
  • Mesmo que vários usuários façam merge de branches em que trabalharam de forma independente em qualquer ordem, o resultado permanece o mesmo
• Com a persistência da ordem das linhas, uma vez definida a ordem de trechos de código inseridos na mesma posição, ela é mantida depois disso
  • Isso evita o problema de áreas de conflito serem resolvidas de forma diferente em cada branch
• Conflitos são tratados apenas como marcações informativas e não bloqueiam o merge
  • O resultado do merge é sempre gerado, e os conflitos são marcados como “partes modificadas simultaneamente em posições próximas”
  • O sistema rastreia o autor e a ação de cada mudança para fornecer marcações de conflito úteis
• O histórico fica incorporado à estrutura
  • O estado é representado por uma estrutura 'weave' que contém todas as linhas do arquivo, incluindo metadados sobre quando cada linha foi adicionada ou removida
  • No merge, basta fornecer dois estados, sem procurar um ancestral comum nem percorrer um DAG, e o resultado correto sempre é gerado

Marcações de conflito aprimoradas

• Sistemas tradicionais de controle de versão, quando há conflito, apenas mostram dois blocos de código lado a lado, obrigando o usuário a deduzir manualmente a diferença
• Manyana explicita cada área de conflito com rótulos como “removido” e “adicionado”, além de mostrar quem fez qual mudança
  • Por exemplo, se um usuário remove uma função e outro adiciona uma linha dentro dela, o Manyana mostra claramente a estrutura de cada mudança separadamente
  • Assim, em vez de comparar dois blocos, o usuário consegue entender imediatamente o significado e o contexto das mudanças

Redefinindo o rebase

• Em um sistema baseado em CRDT, o rebase não destrói o histórico
  • O rebase tradicional reempilha commits sobre uma nova base, criando um histórico fictício
  • No Manyana, obtém-se o mesmo efeito, mas todo o histórico original é preservado
• Para isso, basta adicionar ao DAG uma anotação de “ancestral principal (primary ancestor)”
• Esse método funciona de forma estável mesmo em estruturas de merge sem ancestral comum, evitando falhas do merge 3-way tradicional

Estado atual do projeto

• Manyana é uma implementação de demonstração, não um sistema completo de controle de versão, e funciona por arquivo individual
  • É composto por cerca de 470 linhas de código Python
  • Os recursos de Cherry-pick e undo local ainda não foram implementados, mas o README apresenta a direção futura para isso
• O projeto demonstra que o controle de versão baseado em CRDT pode resolver problemas de UX e oferecer resultados melhores do que as ferramentas existentes
• Todo o código é distribuído em domínio público (public domain), e toda a documentação de design está incluída no README do GitHub

Resumo da reação da comunidade

• Um usuário comentou positivamente sobre a tentativa do Manyana, avaliando que, embora o Git seja usado há mais de 10 anos, é necessário um novo paradigma de controle de versão
  • Apontou que a ideia de o merge sempre funcionar não é intuitiva e pediu mais exemplos e explicações
  • Demonstrou interesse na ideia de melhorar o rebase e mencionou usar, em projetos pessoais, um método de gerenciamento de merge por meio de branches intermediárias
  • Também apontou limitações do Git como tratamento de arquivos binários, confusão na distinção entre branch esquerdo e direito e falta de resumo para grandes mudanças de código
  • Sugeriu que futuros sistemas de controle de versão poderiam oferecer recursos token-aware ou plugins específicos por linguagem e formato de arquivo
• Outro usuário perguntou se o Manyana tem uma base semelhante à do Pijul ou Darcs, pedindo uma comparação entre os problemas de desempenho do Darcs e o estado atual do Pijul

Conclusão

• Manyana é uma demonstração prática da aplicação de CRDT ao controle de versão, redesenhando de forma fundamental o tratamento de conflitos e o problema do rebase
• Uma estrutura sem falhas de merge, a transformação dos conflitos em informação e a incorporação estrutural do histórico apontam para uma direção de design que vai além das limitações do modelo atual do Git
• Não é um sistema completo, mas é um ponto de partida significativo como blueprint de design para sistemas de controle de versão de próxima geração

[GN⁺]

Comentários do Hacker News

• Acho que a forma de exibir o merge é uma questão separada da representação do histórico
  Eu também não gosto da UI de merge padrão do Git, então uso p4merge. É uma ferramenta que mostra quatro painéis (esquerda, direita, base comum e resultado), então dá para ver de relance a causa do conflito e como resolvê-lo
  Não acho que seja necessário trocar o próprio VCS por causa disso

  • Mesmo sem usar p4merge, se você mudar a configuração merge.conflictStyle do Git para "diff3" ou "zdiff3", a versão base também passa a ser exibida
    Assim, só olhando os marcadores de conflito já dá para inferir qual lado adicionou o código novo
  • A maioria das pessoas não pensa muito a fundo nesse problema
    Fiquei surpreso quando ouvi num podcast um convidado que criou um novo VCS entender errado o modo como o Git armazena diffs. Ver alguém tocar um projeto por anos sem sequer pesquisar os conceitos básicos mostra que o espírito NIH (reinventar a roda) continua vivo
  • Também recomendo p4merge. Se fazer merge no Git é doloroso, isso parece mais um problema de design de UX do que conceitual
  • IDEs da JetBrains (como IntelliJ) também oferecem uma ótima UI de merge
    Mas fazer isso no nível do SCM tem a vantagem de poder lembrar o histórico de merges do usuário. O Git tem alguns casos de borda nessa parte
  • Fico curioso se ele também consegue fazer merge de diretórios comuns

• Não sei se é realmente bom que o merge nunca falhe
  Falha de merge muitas vezes não é só conflito de posição, mas um sinal de conflito semântico. Nesses casos, é preciso resolver manualmente

  • O sistema proposto também diz que mostra ao usuário quando há mudanças sobrepostas. A diferença para o Git parece mais uma questão de padrão de comportamento
  • Na prática, mesmo quando o merge dá certo, às vezes o resultado é um código que nem compila. Já tentei usar ferramentas de IA para resolver conflitos de merge, mas especialmente em rebase elas não funcionam bem
  • A ideia desse sistema não é que ele nunca falhe, e sim que permita continuar o merge enquanto marca os conflitos. O jj tem uma abordagem parecida
  • Tentar capturar problemas semânticos dependendo só de merge de texto tem limites. Em vez disso, acho melhor usar verificações pós-merge ou validação de intenção baseada em agentes

• Acho que CRDT não é adequado para controle de versão
  Conflitos são parte essencial do controle de versão. Se dois desenvolvedores alteram o código em direções diferentes, no fim é preciso fazer uma escolha semântica. Em situações assim, CRDT pode acabar produzindo um código sem sentido
  Já existem muitas ferramentas que oferecem uma UX de merge melhor sobre o Git, e a facilidade de fazer cherry-pick ou revert também é uma vantagem do Git

  • Claro que merge automático resolve só conflitos sintáticos; os conflitos semânticos continuam existindo
    Por exemplo, se uma branch remove uma constante e outra branch usa essa constante, o código quebra
    Como os conflitos do Git em geral são sintáticos, uma abordagem de semantic merge mais inteligente ou até CRDT pode ajudar
  • Dá para usar CRDT apenas no cálculo de merge
    Por exemplo, ao rastrear nomes de arquivos, atributos e hashes, pode-se usar um OR-set(https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type).
    Ainda assim, a resolução de conflitos precisa continuar sendo tratada numa interface externa

• Não entendo muito bem por que tanto foco em CRDT
  O problema semântico dos conflitos continua existindo. Pior: as mudanças podem aparecer intercaladas (interleave), o que deixa tudo mais confuso
  Eu sou partidário de rebase. Deve-se evitar commits de merge, e todo commit deveria ser uma unidade independente. Acho Gitflow um antipadrão
  Jujutsu e Gerrit resolvem muito bem o verdadeiro problema do Git: “gerenciar uma cadeia de commits baseada em feedback de review”

  • O importante é o que se entende por “unidade de trabalho (unit of work)”
    O Git reaplica snapshots, então o mesmo trabalho acaba existindo duas vezes. Já o Pijul opera em unidades de patch, produzindo o mesmo resultado independentemente da ordem. Para mim, isso sim é uma unidade de trabalho realmente independente
  • CRDT pode tratar merge e rebase como o mesmo conceito
    Mesmo em estado de conflito, seria possível desfazer (undo) apenas certos commits. A estrutura pode ser mais flexível que a do Git
  • Se você usar só rebase o tempo todo, vai acabar resolvendo conflito a cada commit, o que é ineficiente
    Na prática, muitas vezes só o resultado final importa. Misturar squash merge de forma apropriada é mais realista
  • É fácil cair na ilusão de que CRDT resolve tudo
    Mas alguns problemas exigem conflito por natureza. Por exemplo, a mistura de caracteres em editores colaborativos pode até gerar um resultado pior

• Este projeto parece expandir ideias do Codeville, que o Bram criou no passado
  O Codeville surgiu no começo dos anos 2000, durante o boom dos DVCS, e usava armazenamento e merge baseados em weave. É uma ideia 10 anos anterior aos CRDTs, mas naturalmente relacionada
  É bom ver que o Bram continua trabalhando nesse problema e tentando coisas novas

  • A verdadeira vantagem dos CRDTs é um modelo de funcionamento fácil de entender. Quando você implementa um, a estrutura fica clara
  • Em 2007, Bram disse que meu algoritmo Causal Tree era uma variação de weave. Desde então, os algoritmos da família weave evoluíram bastante, e há artigos sobre isso
    arxiv:2002.09511
  • CRDT não é uma tecnologia única, e sim um arcabouço conceitual. No fim, o próprio Git implementa eventual consistency, então num sentido amplo também pode ser visto como um CRDT

• Não concordo com a afirmação de que “ainda não existe um VCS baseado em CRDT”
  O Pijul já existe, e é um projeto no qual especialistas investiram milhares de horas

  • Isso não quer dizer que o Bram tenha pouca experiência com VCS. O Codeville já existia há 20 anos
  • Tenho o hábito de verificar todo ano a página teórica do manual do Pijul. Até hoje os erros de formatação em TeX não foram corrigidos
    Está em fase experimental há 6 anos, e eu mesmo abri uma issue há 4 anos, mas ainda não foi refletido
  • No começo achei um repositório antigo no GitHub, mas o repositório oficial real está no Nest.
    O Pijul é um VCS desenvolvido com ele próprio, então não usa GitHub
  • Às vezes, quando executo pijul pull -a, surge conflito e eu simplesmente clono de novo. Fico curioso se existe algum pull para atualização de acompanhamento

• manana.py tem 473 linhas de código Python sem dependências
  A implementação real tem só cerca de 240 linhas; o resto é código de teste. É simples, mas impressionante

  • O próprio nome é uma piada. “Mañana” em espanhol significa amanhã, mas também pode carregar a ideia de “depois a gente vê”. Ou seja, sugere procrastinação
  • Impressiona que algo assim tenha sido feito com algumas centenas de linhas de Python limpo
    Isso me faz lembrar o caso do left-pad no ecossistema JS, e acho que o Python também precisa de mais pacotes pequenos e responsáveis

• Sistemas assim deveriam ser projetados analisando como os conflitos de merge variam conforme o tamanho da equipe
  Equipes de 1, 10, 100 e 1000 pessoas enfrentam problemas diferentes, e também é preciso considerar como o desenvolvimento baseado em agentes mudará isso
  Pela minha experiência, entre 1 e 100 pessoas quase não há conflito porque a equipe divide as subárvores de código.
  Com mais agentes, 100 pessoas talvez passem a se comportar como 1000, mas por enquanto parece mais um caso de solução procurando um problema real

  • Agentes conseguem lidar com qualquer sistema de controle de versão
    Hoje em dia é só jogar o conflito de merge no Codex e pronto, então há cada vez menos motivo para adotar um novo VCS
    O Git foi projetado para equipes grandes, e na era dos agentes dá para responder bem com automação de processos
  • Mesmo com equipes maiores, naturalmente surge especialização por área de código, então a frequência de conflitos tende a ser parecida.
    O problema aparece mais em gargalos de bibliotecas compartilhadas ou em políticas de restrição de acesso
  • Abordar isso por análise de tamanho de equipe talvez seja ineficiente. O mais importante é ter um design conceitualmente consistente

• Mais do que conflitos, o problema maior é a escalabilidade (scalability) do Git
  O tamanho dos repositórios e a velocidade de mudança estão chegando ao limite. É preciso redesenhar servidor, cliente e protocolo como um todo

  • Fico curioso sobre quais problemas de escalabilidade ocorreram. Será que é por causa de monorepos?
  • Uma das soluções é modularizar o código e referenciá-lo por dependências versionadas

• Pessoalmente, não entendo muito bem que problema esse sistema resolve
  Em abstrato é interessante, mas na prática o jj é muito mais útil que o Git
  Acho que o próximo passo é um sistema de controle de versão não no nível de arquivo, mas no nível de AST.
  Houve tentativas como LightTable e Dark; seria interessante experimentar esse tipo de VCS baseado em árvore

  • Já existem iniciativas nessa direção. Um novo sistema de parser está sendo construído