Build LogPublicado em 10 de agosto de 20266 min de leitura

GitRex e a decisão de usar system Git: evitando dois modelos de Git

Uma TUI pode melhorar muito a ergonomia do Git, mas não deveria criar uma segunda implementação das mesmas operações nem comprometer scripts e automação.

  • Rust
  • Git
  • Developer Tooling
  • Arquitetura
  • Ver projeto relacionado

    O GitRex é um gerenciador Git terminal-first escrito em Rust. Em terminais interativos, ele abre uma TUI; em pipes, scripts e outros contextos não interativos, mantém um caminho CLI previsível.

    A decisão mais importante da migração recente não foi visual. Foi reduzir a dependência operacional de libgit2 e delegar as operações de repositório ao Git instalado no sistema.

    A migração foi guiada por alguns invariantes:

    • TUI e CLI precisam observar o mesmo repositório e a mesma semântica operacional
    • Execuções não interativas não podem abrir interface ou depender de estado visual
    • Mutações devem continuar explícitas e rastreáveis ao executável Git
    • A migração precisa ser incremental para preservar o harness de testes enquanto ele também evolui

    Manter bindings Git e system Git como backends equivalentes parece flexível, mas aumenta a superfície de comportamento: parsing de referências, mensagens de erro, autenticação e edge cases podem divergir. Se o usuário já possui Git instalado, delegar a autoridade operacional ao próprio Git reduz esse espaço de inconsistência.

    A arquitetura separa roteamento, estado/controlador da TUI e um adaptador de processos Git. Essa divisão existe porque cada parte muda por motivos diferentes, não para criar abstrações antecipadas.

    O resultado é uma TUI que melhora descoberta e navegação sem se tornar uma API paralela. A CLI permanece como contrato estável para automação.

    Quando uma ferramenta envolve outro sistema complexo, vale mais reimplementar a semântica em uma biblioteca ou compor com a implementação que já é a referência do usuário?

    Para o GitRex, system Git reduz duplicação de conhecimento e mantém o comportamento mais próximo do que o usuário já consegue inspecionar no terminal.

    A escolha não significa que bindings sejam sempre errados; ela muda quando há necessidade real de APIs estruturadas que o processo externo não oferece. O ponto é não carregar dois modelos operacionais sem benefício concreto.

    Trade-off

    Qual complexidade estamos realmente comprando quando mantemos duas formas diferentes de executar a mesma operação?

    Fontes e referências de apoio

    Estas são algumas das obras, estudos e instituições usadas como base conceitual para os argumentos do texto.

    Continue a conversa

    Quer levar essa conversa para um projeto real?

    Se essa reflexão toca em algo do seu momento, posso ajudar a transformar visão, contexto e necessidade em projeto bem resolvido.

    Outros textos do blog para ampliar a conversa entre tecnologia, processo, mercado e experiências reais.