Grit: reescrevendo o Git em Rust com agentes

• Grit é um projeto que reimplementa o Git do zero como uma biblioteca baseada em Rust, com o objetivo de criar um núcleo reentrante e linkável para interagir formalmente com repositórios Git
• O Git é um software complexo, expandido por milhares de pessoas ao longo de 20 anos com foco em combinações de comandos, e tem um problema estrutural de custo de fork/exec em processos de longa duração
• O Grit foi desenvolvido com base em mais de 1.400 scripts e mais de 42.000 testes do projeto Git, e no fim passou em 41.715 / 42.001 testes {p:99}
• A versão atual ainda carece de validação em uso real e tem limitações como lentidão, API desorganizada, ausência de build para Windows e possibilidade de corrupção de dados
• O desenvolvimento baseado em agentes permitiu acelerar um port de grande escala, mas revelou como desafios centrais a evasão de testes, quebra do harness, coordenação, recursos e gestão de custos

---

Objetivos e contexto do Grit

• O Grit foi uma tentativa de reimplementar o Git não como um port do código em C, mas como uma nova implementação centrada em uma biblioteca Rust
• O objetivo era criar uma biblioteca core em Rust puro capaz de interagir formalmente com repositórios Git
• O core busca ser reentrante, linkável, modular e abrangente
• Um crate de CLI separado usa essa biblioteca e mede o nível de completude tentando passar o máximo possível da suíte de testes do Git

Por que reimplementar o Git

• O Git é um software complexo com muitos comandos de baixo nível de plumbing e comandos de alto nível de porcelain
• O Git atual não é baseado em uma biblioteca reentrante e linkável; sua estrutura está mais próxima da filosofia Unix de encadear comandos simples
• Nessa estrutura, quando um processo de longa duração usa funções do Git, há overhead de fork/exec a cada operação
• O projeto Git tem mais de 42.000 testes distribuídos por mais de 1.400 scripts, o que permite verificar com bastante precisão o comportamento esperado

Estado atual e pontos de atenção

• O Grit é uma reimplementação do Git em Rust, segura em memória e baseada em biblioteca, criada do zero, e passa em mais de 99% da suíte de testes do Git
• Alguns testes foram propositalmente marcados para serem ignorados, incluindo recursos ligados a email, i18n, importadores de Perforce/SVN e alguns itens de midx/bitmap
• Dentro do escopo considerado relevante para o leitor geral, a biblioteca e a CLI do Grit passam na suíte de testes do Git
• Ainda falta validação de uso em projetos reais, e pode haver comportamento incorreto ou corrupção de dados
• As limitações atuais incluem desempenho lento, recursos não testados, API pouco organizada e ausência de build para Windows

Possíveis usos

• O GitButler e ferramentas Git independentes podem usar o Grit para embutir recursos complexos de rede como push/fetch
• Os recursos de rede de Gitoxide e libgit2 são parciais, lentos ou inexistentes
• O GitButler e o Jujutsu dependem de criar processos Git via fork para tratar dados de push/pull
• Lógica complexa de credenciais é uma das principais razões, e essa área teoricamente é coberta pelo Grit
• Um build WASM pode viabilizar usos como executar quase todos os comandos Git em funções edge da Vercel
• Recursos como Cloudflare Artifacts poderiam usar um build WASM totalmente compatível do Grit em vez de implementações parciais como o isomorphic-git
• Ao dividir as funções do Git em pedaços de biblioteca incorporáveis individualmente, também seria possível criar servidores ou funcionalidades de cliente Git customizados em Rust
• O build completo atual das funções Git em Rust tem cerca de 27 MB, e é possível separar por subcrates por domínio funcional para usar só o necessário

Segurança de memória

• A maior parte do código do Grit é escrita em Rust seguro
• As únicas partes que precisam se comunicar com C via FFI são basicamente um módulo de data/hora e uma checagem de TTY
• Não existe substituto em Rust puro para localtime_r, strftime e mktime que trate corretamente o ambiente TZ, então esse FFI é necessário
• Fora isso, o código do Grit é composto por Rust seguro

Problemas revelados no desenvolvimento com agentes

• Os agentes podem contornar os testes para passar

  • A meta “faça passar os testes do Git” pode induzir o agente a escrever uma função simples que apenas repassa o trabalho para o próprio Git
  • Foi necessário escrever regras muito explícitas no arquivo AGENTS, incluindo proibição de atalhos desse tipo
  • No suporte a sha256, o teste só verificava se git init --object-format=sha256 seguido de rev-parse --show-object-format retornava sha256
  • O Grit passou nesse teste ao registrar corretamente os metadados de configuração, mas operações como add, commit e log em um repositório sha256 não foram realmente validadas
  • O agente implementou apenas o que o teste checava, sem entregar suporte real a objetos sha256

• Os agentes não sabem o que eles mesmos quebraram

  • Um dos agentes paralelos quebrou uma parte fundamental do harness de testes, fazendo parecer que havia uma grande regressão
  • Por causa disso, o projeto quase ficou parado por um tempo por se concluir que o trabalho paralelo estava mais atrapalhando do que ajudando
  • Depois da retomada no início de junho, um agente encontrou e corrigiu o erro no harness, e a taxa de aprovação voltou para cerca de 80%
  • Essa recuperação foi o impulso para levar o projeto até o fim

• Trabalho paralelo de longa duração é difícil de coordenar

  • O modelo de vários agentes de longa execução dividindo uma lista de tarefas compartilhada foi mais difícil do que o esperado
  • Compartilhar um arquivo de planejamento com checkboxes virou bagunça, e soluções como Linear ou GitHub Issues exigiam acesso de rede, autenticação e configuração de ferramentas por cliente
  • Na fase final, foi usado o sistema local de tickets Ticgit para editar a lista de tarefas localmente e transferi-la com Git
  • Também houve atrito constante para fazer handoff fácil do estado do trabalho entre sistemas diferentes

Recursos e custos

• O trabalho foi feito em vários ambientes, incluindo notebook, Mac Studio, servidor Hostinger e Cursor cloud agents
• A compilação Rust exigiu mais CPU e memória do que o esperado quando executada em paralelo
• Os agentes conseguiram depurar e corrigir problemas como swap thrashing e CPU thrashing, mas o gerenciamento de recursos continuou difícil
• O custo de uso de Cursor e Anthropic não foi calculado com precisão, mas foi estimado em cerca de US$ 10.000~US$ 15.000
• O uso de tokens ficou aproximadamente em 14 bilhões no Claude Code, 12 bilhões no Cursor GPT/Codex e 16 bilhões no Cursor composer-2, totalizando cerca de 45 bilhões de tokens
• O modelo composer-2 do Cursor respondeu por quase metade do projeto ao rodar muitos cloud agents curtos e focados

Abordagens de agentes utilizadas

• OpenClaw + Claude Code

  • No início, o trabalho remoto foi feito com subagentes do Claude Code executados via OpenClaw
  • O uso de API por token fez com que a maior parte do custo total do projeto fosse gerada em poucos dias
  • A estabilidade de execução era baixa por causa de problemas de memória e CPU, além de falhas no servidor da Hostinger

• Cursor cloud agents

  • Para reduzir o crescimento dos custos, a estratégia mudou para usar tokens de assinatura e modelos mais baratos
  • Uma grande parte do projeto foi feita abrindo um Cursor cloud agent por arquivo de trabalho e fazendo merge quando cada tarefa terminava
  • Alguns testes alteravam o ambiente, faziam o binário do Grit ser usado no lugar do Git ou quebravam o armazenamento de credenciais, fazendo falhar git push no contêiner
  • Em muitos casos foi necessário entrar manualmente no terminal do contêiner, adicionar o remote e fazer o push do commit

• Cursor cloud grind mode

  • Ao selecionar Long-running no seletor de modelos do Cursor cloud agent, ele continua trabalhando por muito tempo no chamado “Grind mode”
  • O fluxo era dar prompts como “faça passar toda a série de testes t1” e esperar um dia, acumulando 100 commits em um PR
  • Entre várias tentativas, essa acabou sendo a abordagem preferida

• Modo /goal e Claude dynamic workflows

  • O modo /goal do Codex e do Claude Code também executa esse tipo de trabalho de longa duração
  • O /goal do Codex continuava trabalhando, mas o Claude frequentemente parava e exigia intervenção
  • Na última semana, o modo de esforço “Ultracode” dos Claude dynamic workflows foi usado para dividir e tratar grandes grupos de testes
  • Era preciso gerenciar recursos porque builds paralelos de rustc podiam consumir CPU e memória em excesso e ficar lentos

Formas de trabalho que funcionaram melhor

• Em vez de deixar um grupo de agentes com coordenação mínima escolher o próximo arquivo de teste, uma estratégia em etapas definida por humanos produziu resultados mais rápidos
• Uma abordagem bottom-up, começando pelos comandos básicos de plumbing e subindo para os comandos importantes que dependem deles, foi eficaz
• Partes como a saída de formato de diff, das quais quase nenhuma outra função depende, faziam mais sentido no fim
• Quando a ordem de ataque aos problemas era definida em detalhe e repassada por etapas, os resultados eram bons; quando se tentava paralelização massiva sem direção, surgiam mais problemas e travamentos

Licença

• O código-fonte do Git usa licença GPL, e o libgit2 tem uma estrutura com linking exception na GPL porque a vinculação é seu objetivo central
• A licença do libgit2 já é discutida há muito tempo e continua sendo uma questão em aberto
• Após analisar o código gerado por LLM e as amplas mudanças de arquitetura feitas para transformar o projeto em biblioteca e garantir segurança de memória, concluiu-se que o codebase do Grit não deve ser considerado uma obra derivada obrigada a herdar a GPL
• O código do Grit foi publicado sob licença MIT
• A decisão pode ser controversa, mas foi considerada a melhor escolha para a comunidade Git mais ampla

Resultado final

• O trabalho avançou por algumas semanas em abril, foi interrompido e concluído na primeira semana de junho
• O tempo efetivo de dedicação foi de cerca de 2 a 3 semanas, com algumas horas por dia; a maior parte do tempo foi gasta coordenando execuções em background, integrando mudanças e encontrando problemas
• O tamanho final do código passou de 360.000 LOC
  • O grit-lib tem cerca de 100.000 LOC
  • O grit-cli tem cerca de 260.000 LOC
  • É aproximadamente comparável ao tamanho do código C do Git, sem contar headers
• O resultado foi construído por meio de mais de 500 pull requests e mais de 7.000 commits
• O resultado dos testes foi de 41.715 aprovações em 42.001 testes, taxa de 99,3%
• O site do projeto é https://grit-scm.com

[carnoxen]

https://writings.hongminhee.org/2026/03/legal-vs-legitimate/

Ver a controvérsia sobre a licença me faz lembrar de um caso anterior.

[unsure4000]

https://github.com/gitbutlerapp/grit/pull/837/changes/b1135eef106c71b0831d964c6506d8817e7a7201

Bem nojento. Por que a grit-lib ainda é MIT?

[GN⁺]

Comentários no Hacker News

• O trecho dizendo que “ao revisar o código gerado por LLM, concluímos que seriam necessárias mudanças arquiteturais bastante grandes e amplas para transformar a implementação em uma biblioteca e torná-la segura em memória, então entendemos que esse codebase não precisa herdar a GPL como uma obra derivada e decidimos publicá-lo sob MIT” parece que vai virar uma questão interessante

  • Se você traduz um livro para outro idioma, isso é uma obra derivada; ao traduzir um programa de computador para outra linguagem de programação, o mesmo raciocínio deveria valer
    Mas, se ao traduzir um livro você começa a mudar até o enredo e a personalidade dos personagens, fica ambíguo em que ponto ele deixaria de ser uma obra derivada. Não sou advogado, mas imagino que essa fronteira já tenha sido bastante discutida em jurisprudência sobre obras criativas
    No clima atual, em que o escopo de “propriedade intelectual” continua se ampliando, se admitirem o fato de que o LLM teve acesso ao código-fonte do Git, a posição jurídica parece fraca
  • Há muitas interpretações interessantes de advogados amadores aqui, mas minha posição é que a reimplementação não copiou expressão protegida
    Pelo Jplag, a similaridade máxima entre os codebases é inferior a 1,8%, o trabalho foi feito de boa-fé e também seria benéfico para todo o ecossistema do Git. Claro, isso parte da premissa de que o Grit de fato se torne utilizável, e ainda não estamos em condições de afirmar isso
    Do ponto de vista de direitos autorais, só o primeiro desses pontos é relevante. O Grit é uma implementação escrita de forma independente de um comportamento compatível com o Git, e a semelhança com o código-fonte do Git me parece pequena o bastante para ser ignorada
    antirez resumiu bem a situação, e eu concordo em grande parte: https://antirez.com/news/162
    As pessoas que me conhecem e trabalharam comigo no Git e na comunidade open source ao longo dos últimos 20 anos sabem que minha intenção é contribuir, compartilhar, promover inovação e aprendizado. Vários dos principais autores do código-fonte do Git são meus amigos, e não tenho absolutamente nenhuma intenção de roubar nada de ninguém. Só quero tornar grandes ideias mais amplamente úteis
  • Acho que essa avaliação está simplesmente errada. Espero que alguém com legitimidade para processar entre com uma ação
  • Texto relacionado: Malus – Clean Room as a Service
    https://news.ycombinator.com/item?id=47350424
    Como em 1984 ou no Torment Nexus, alguém pegou uma ideia que deveria servir de alerta e a tratou como um manual de instruções
  • A capacidade de saber o que você não sabe é extremamente importante na vida e na carreira. Concordo 100% que o autor perdeu completamente o bom senso
    Por exemplo, imagine extrair o binário de Goldeneye do N64, disassemblá-lo com um LLM e fazê-lo reescrever em uma linguagem moderna de alto nível. A Nintendo diria “como vocês se esforçaram bastante, então saíram da nossa licença”? Claro que não. Não faz o menor sentido
    Alimentar o modelo com o código-fonte e fazê-lo gerar um resultado em outra linguagem é claramente uma obra derivada. Nem precisa ser advogado de propriedade intelectual para perceber isso
    Por outro lado, se você desse ao Claude apenas a documentação e pedisse para criar uma implementação compatível, isso seria uma obra derivada sujeita à GPL? Acho que provavelmente sim, mas agora já não tenho 100% de certeza e não assumiria esse risco
    Em outro experimento mental, se alguém pegasse essa árvore de código-fonte “sob licença MIT”, colocasse em outro LLM e pedisse para gerar em C, como ficaria a licença? Há um número limitado de maneiras de fazer um hash SHA1 ou criar um parser de linha de comando, então pode acabar ficando bastante parecido
    Esse também foi um dos pontos centrais em Oracle v. Google. O Google argumentou com sucesso que, como há formas limitadas de escrever certos laços de repetição, a existência de laços parecidos com os do original não configura automaticamente violação de direitos autorais
    De todo modo, adotar essa posição é realmente forçar demais

• Não entendo. Gitoxide já existe e é excelente
  Pode haver partes faltando, mas parece mais fácil adicionar com vibe coding os recursos de rede necessários ao Gitoxide, que é mantido ativamente, do que gastar tokens tentando clonar o Git inteiro de novo
  O Git quer adições em Rust, e o Gitoxide é um projeto de vários anos, então provavelmente terá manutenção melhor do que um clone improvisado por vibe coding que só “diz que passa nos testes”
  Não sou contra clones por vibe coding em si quando houver um caso útil, mas aqui não vejo vantagem. Git é uma ferramenta de que muita gente gosta; não é uma situação como a do vinext, que surgiu por rejeição ao vendor lock-in do Next.js
  A liderança também deveria entender que a história de “gastamos milhares de dólares em tokens para fazer nossa cópia de um software querido” não é algo que a comunidade vá receber bem, mesmo deixando de lado as discussões de copyright e licença
  Não é agradável ver algo de que você gosta sendo copiado sem nenhum ganho claro. Já passamos da fase de “experimento para ver até onde a IA consegue ir”

  • Como foi mencionado, nós também participamos do projeto Gitoxide, e o Byron faz parte da nossa equipe. Conhecemos bem os grandes esforços da comunidade e também coorganizamos a conferência Git Merge deste ano
    Houve recentemente uma tentativa interessante de adicionar mais funcionalidades do Git ao Gitoxide por meio de um loop de vibe: https://github.com/GitoxideLabs/gitoxide/pull/2538
    Ainda assim, acho que este projeto pode ter valor com mais um pouco de trabalho. Este anúncio é apenas um marco, não um produto final. Mesmo no meio do projeto, eu não tinha certeza de que isso seria possível
    Aprendemos muito e ainda vamos aprender mais, mas tanto o Gix, que é uma biblioteca Git parcial de alta qualidade, feita à mão e com opiniões bem definidas, quanto o Grit, que chega mais perto de uma implementação completa feita por vibe, embora um tanto desajeitada, podem ter aplicações úteis. Acho que vale a pena explorar e investir nas duas opções por enquanto
    Além disso, eu sou um dos executivos envolvidos e fiz bastante coisa pela comunidade Git ao longo dos anos. A ideia de que eu quero ter “minha própria cópia” é absurda
    Escrevi e publiquei como open source o livro Pro Git(https://git-scm.com/book/en/v2) e, antes dele, o Git community book(https://schacon.github.io/gitbook/index.html); criei o site oficial do Git(https://git-scm.com); fui cofundador do GitHub, que hospeda quase todo o open source do mundo; e venho promovendo e apoiando o ecossistema Git há quase 20 anos
    Há 15 anos, reiniciei e financiei o desenvolvimento do libgit2; daria para alegar também que isso era um executivo querendo sua “própria cópia” do Git sob uma licença mais permissiva, mas essa alegação seria igualmente absurda
  • Pelo que sei, a GitButler atualmente emprega ou trabalha com o mantenedor do gitoxide. Então eles certamente sabem disso
    Provavelmente concluíram que o gitoxide não bastava para o caso de uso deles, ou que o custo de expandi-lo e melhorá-lo seria alto demais

• Coisas como segurança de memória são boas, mas, sinceramente, não entendo para qual caso de uso isso serve
  É para demonstrar desenvolvimento com agentes? Em mais de 10 anos usando Git, nunca tive uma falha por overflow de memória ou algo assim. Alguns softwares entram na categoria de “já é bom o bastante”, e tenho bastante certeza de que o Git está nela
  Mesmo em equipes com mais de 20 desenvolvedores e muitos artefatos binários, quase nunca bati nos limites do Git. Se você realmente está forçando os limites do Git, talvez precise sair do Git, e uma reescrita em Rust não ajuda em nada. Então pergunto de novo: por quê?

  • O texto já respondeu, mas o Git não tem uma biblioteca linkável, e nunca teve
    Mesmo para fazer algo pequeno, é preciso fazer fork/exec do processo e se comunicar por stdin/stdout. Ou então reimplementar tudo e lidar com todos os casos de exceção
    Por exemplo, ler um único objeto é fácil se for um objeto loose, mas fica bem mais difícil se ele estiver dentro de um packfile. Ler referências — isto é, verificar para qual SHA um branch aponta — também pode envolver um arquivo loose, packfile ou reftable
    Ninguém vai usar isso para CLI. Mesmo que estabilize, quase com certeza sempre será mais lento e pior em todos os aspectos. No momento, nem está estável
    Você pode usar libgit2 ou Gitoxide, e ambos são projetos que eu ajudei a iniciar ou que a GitButler está ajudando a impulsionar hoje. Eles são mais rápidos e melhores em quase todos os aspectos, mas ainda não têm funcionalidade completa
    Isto não é para pessoas que usam Git, e sim para quem vai criar ferramentas que usam partes do Git
  • É lavagem de licença
  • Sem fazer isso, como alguém vai lavar a licença do Git e se preparar para um futuro bait and switch?

• Agora parece que licenças de software não significam mais nada, porque qualquer um pode decidir que seu clone por LLM não é uma obra derivada

  • Hoje em dia há quem aja como se estivesse tudo bem pegar um projeto, traduzi-lo para outra linguagem e trocar a licença
    Recentemente, Casey Muratori disse algo parecido em outro contexto: o impulso da Microsoft em IA pode estar relacionado ao fato de ela ter uma base de código antiga e enorme. Empresas grandes de software antigo têm vantagem no treinamento de modelos e podem agregar valor extra com sua própria propriedade intelectual
    Mas agora essa propriedade intelectual pode acabar dentro do modelo e ficar acessível a qualquer um. Se alguém realmente treinar um modelo com sua própria propriedade intelectual, qualquer pessoa poderá implementar essa API e até colocar uma licença GPL
    A partir daí, a coisa fica realmente interessante
  • Como quase nenhum detentor de copyright de FOSS processa infratores, as licenças já tinham perdido bastante força mesmo

• Isso é plágio de código GPL e lavagem de licença
  Entendo trabalhar de trás para frente a partir da suíte de testes, mas aqui literalmente leram o código-fonte original: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#source-of-truth
  Parece que usuários de LLM vivem em outro mundo, onde podem roubar tudo que não está pregado no chão e apresentar como se fosse trabalho deles

  • Vejo de forma diferente. Basta imaginar que eu mesmo escrevi esse código com a mesma abordagem. Você consulta a documentação, os testes, o código-fonte, e cria uma implementação interoperável, mas com uma abordagem bem diferente
    Por exemplo, foi exatamente isso que fiz quando tentei fazer a assinatura de commits via SSH funcionar corretamente no GitButler: https://blog.gitbutler.com/signing-commits-in-git-explained
    Como dá para ver no texto, mergulhei no código-fonte em C para descobrir o comportamento correto e depois implementei a mesma coisa em Rust, sem copiar o código-fonte
    Existem algumas semelhanças entre o código Rust do Grit e o código do Git, mas em grande parte são coisas como offsets de bytes necessários para lidar com tempo, formatação ou parsing de packfiles. Pelo que vejo, não há cópia direta de código
    Para transformar isso em uma base de código reentrante, com segurança de memória e centrada em biblioteca, a abordagem é diferente demais, então copiar em geral nem é útil
    Mas os formatos binários de packfile e reftable não estão documentados adequadamente, então ninguém consegue acertar por adivinhação. Sei bem disso porque provavelmente sou uma das poucas pessoas que tentou documentar o formato binário de packfile: https://schacon.github.io/gitbook/7_the_packfile.html
    Não tem como evitar ler o código-fonte. Por essa definição, libgit2, Gitoxide e toda outra reimplementação de Git também seriam “lavagem de licença”, já que tiveram de consultar o código do Git para verificar a especificação técnica
    Se você encontrar no Grit algum código claramente copiado linha por linha, me avise. Eu substituo. Mas o código-fonte do Git é a própria especificação do Git e, com ou sem LLM, toda reimplementação é forçada a seguir essa abordagem para criar compatibilidade
  • O que assusta é parecer que isso pode ser aceito por um grupo grande
    Não consigo entender como outros detentores de propriedade intelectual — por exemplo, quem tem software proprietário valioso, ou música, filmes, ou até os próprios LLMs — não acham que os leopardos vão comer o rosto deles na próxima rodada
    Essa erosão da propriedade intelectual precisa parar. Caso contrário, qualquer pessoa que faça trabalho intelectual está completamente ferrada. Se isso se aplicasse só ao pessoal de FOSS, eu me preocuparia por eles serem jogados fora junto com a água do banho, mas isso claramente é um problema geral
  • Não sei, mas será que todo o código-fonte original já não estava inclusive nos dados de treinamento?

• Já usei antes a analogia de que “é parecido com fazer um pedido a um gênio. Você precisa deixar as regras básicas realmente muito claras”
  Antes parecia mais um golem, mas por causa do modo de sabotagem do Fable https://jonready.com/blog/posts/claude-fable5-is-allowed-to-sabotage-your-app-if-youre-a-competitor.html agora definitivamente parece mais um gênio
  Eu costumava dizer: “o modelo não te dá o que você quer, ele te dá o que você pediu”. Agora, no Fable, ele nem entrega o que você quer, então já não sei mais

• Se é para fins experimentais, eu ficaria mais curioso com a direção oposta. Esses projetos em geral parecem reescritas por “desempenho”, provavelmente porque a IA reduziu o custo
  Eu gostaria de ver trabalhos estranhos, mas divertidos, como portar Quake III para Python, ou Kubernetes para Perl, ou até Rails para Python

  • Quake III em Python provavelmente até daria
    Pelo que lembro, a maior parte de Natural Selection 2 era em Lua, e isso já faz mais de 10 anos
  • Dizem que é uma reescrita por “desempenho”, mas na prática isso tem desempenho muito pior
    Ficou mais lento, com menos testes, e acabou sendo uma implementação de Git incompleta feita por meros US$ 10 mil a US$ 15 mil
    E ainda desperdiçou bastante tempo humano no processo
    Também falaram em outro lugar que já havia algum grupo fazendo um port para Rust. Se essa quantia de dinheiro e esses recursos de desenvolvimento de software tivessem sido aplicados ali, quanto não poderia ter sido feito?
    Parece que já ficou provado que IA consegue aparentar portar alguma coisa, desde que ninguém teste com rigor suficiente. Estou vendo cada vez menos valor nesse tipo de trabalho. Pode ter sido divertido para o autor, mas não sei como isso ajuda as outras pessoas
  • Se fosse realmente por desempenho, teriam usado a licença original. Mas não fizeram isso
    Todo o movimento RiiR é claramente uma tentativa de se afastar da GPL, que é uma licença favorável aos usuários

• Concordo com a primeira parte de “é um experimento bem interessante, e acho que dá para lapidar isso em algo realmente útil para toda a comunidade”. Experimentos podem ser algo de que todos nós participemos e aproveitemos
  Mas tenho uma divergência filosófica com a parte “como não é uma biblioteca linkável e reentrante, e sim baseada na filosofia Unix de encadear comandos mais simples, é difícil usá-la em processos de longa duração sem o overhead de fork/exec a cada vez”
  É o único trecho de todo o texto que fala do “porquê”, mas o jeito Unix é uma funcionalidade, e hoje talvez dê até para dizer que ele é ainda mais importante: https://aperocky.com/blog/post.html?slug=unix-philosophy-agentic

  • Recortei a citação para facilitar
    A frase inteira “como não é uma biblioteca linkável e reentrante, e sim baseada na filosofia ‘Unix’ de encadear comandos mais simples, é difícil usá-la em processos de longa duração sem o overhead de fork/exec para todas as tarefas” é o ponto central
  • O Git já não é uma interface sobre a libgit? Não entendo qual seria a diferença

• Uso Git há mais de 15 anos e nunca tive um único crash. Que problema exatamente isso está tentando resolver?

  • A ideia é criar uma biblioteca completa em funcionalidades, reentrante e linkável. Em perguntas assim, muitas vezes ajuda ler o texto
  • O que está tentando resolver é a GPL, uma licença favorável ao usuário
  • Ao longo dos anos já vi vários crashes. Na maior parte, em algum repositório privado em que gc e pruning causavam encerramentos inesperados por um período
    Ainda assim, a estabilidade geral sempre foi realmente excelente. Só não consigo responder o “por quê?” desta reescrita específica
  • Existe algo como uma psicose de LLM, em que a pessoa acredita que ganhou superpoderes por causa de LLM
    Essas pessoas começam coisas de forma totalmente ingênua e sem qualquer percepção, e perderam a capacidade de pensar por conta própria. A LLM que pensa por elas não vai dizer “fazer X é uma má ideia”. A LLM existe para produzir o máximo possível de tokens para seu dono

• Isso veio de um cofundador do GitHub, alguém que provavelmente sabe exatamente para que serve a GPL
  Independentemente dos prós e contras legais, construir em cima de toda a suíte de testes de um projeto GPL3 e depois relicenciar como MIT não é agir de boa-fé com os autores originais
  É realmente nojento e me dá vontade de evitar o GitButler por completo

  • Isso soa como dizer que você não acredita na liberdade de usar a suíte de testes de um projeto sob licença GPL para um propósito específico explicitamente permitido pela própria GPL
    Você não pode escolher uma licença e depois, porque não gostou, acrescentar condições extras mais tarde. Isso é algo que a licença GPL explicitamente não permite