Crítica justa, mas nesse caso foi uma mais escolha de arquitetura.

O Anchor não nasceu com a proposta de reimplementar o Git nem de virar uma engine própria de versionamento. Ele nasceu para ser uma camada em cima do Git real, preservando o comportamento exato que o usuário já tem no ambiente dele.

Usar o binário do Git tem algumas vantagens importantes para esse tipo de ferramenta:

• compatibilidade total com o comportamento do Git que o usuário já usa
• respeito a config, hooks, aliases, credenciais e fluxo real da máquina
• zero divergência entre “o que o Git faria” e “o que o Anchor acha que o Git faria”
• passthrough transparente para praticamente qualquer comando

Se eu trocasse isso por libgit2 logo de cara, eu ganharia uma API mais estruturada em alguns pontos, mas também mudaria bastante a natureza do projeto. O Anchor deixaria de ser uma camada sobre o Git e passaria a assumir parte da responsabilidade de reproduzir comportamento de Git internamente.

Para um wrapper focado em UX, diagnóstico, análise de risco, recovery e explicação contextual, estar em cima do Git real me pareceu uma escolha mais coerente no momento.

Dito isso, eu concordo que existem partes onde uma abordagem mais estrutural pode fazer sentido no futuro. Especialmente leitura de estado, inspeção de repo e algumas operações mais analíticas. Então não vejo “spawn de processo vs libgit2” como dogma, e sim como trade-off.

Hoje a escolha foi: maximizar compatibilidade e previsibilidade primeiro.
Amanhã, conforme o projeto amadurecer, dá para avaliar onde faz sentido incorporar algo mais baixo nível.