Build LogPublished on August 10, 20266 min read

GitRex and system Git: avoiding two models of Git

A TUI can improve Git ergonomics, but it should not create a second implementation of the same operations or compromise scripts and automation.

  • Rust
  • Git
  • Developer Tooling
  • Architecture
  • View related project

    GitRex is a terminal-first Git manager written in Rust. Interactive terminals open a TUI; pipes, scripts and other non-interactive contexts stay on a predictable CLI path.

    The most important recent migration decision was not visual. It was reducing operational dependence on libgit2 and delegating repository operations to the Git executable installed on the system.

    The migration is guided by a few invariants:

    • TUI and CLI must observe the same repository and operational semantics
    • Non-interactive execution must never open UI or depend on visual state
    • Mutations should remain explicit and traceable to the Git executable
    • The migration must be incremental so the test harness can evolve without losing coverage

    Keeping bindings and system Git as equivalent backends sounds flexible, but it expands the behavior surface: reference parsing, errors, authentication and edge cases can diverge. When the user already has Git installed, delegating operational authority to Git reduces that inconsistency space.

    The architecture separates routing, TUI state/controller and a Git process adapter. Those boundaries exist because the responsibilities change for different reasons, not to create speculative abstractions.

    The result is a TUI that improves discovery and navigation without becoming a parallel API. The CLI remains a stable automation contract.

    When a tool wraps another complex system, is it better to reimplement semantics in a library or compose with the implementation that already defines the user's behavior?

    For GitRex, system Git reduces duplicated knowledge and keeps behavior closer to what users can inspect directly in their terminal.

    Bindings are not inherently wrong; the decision changes when structured APIs provide a concrete requirement the external process cannot satisfy. The point is to avoid carrying two operational models without a real benefit.

    Trade-off

    What complexity are we actually buying when we maintain two different ways to execute the same operation?

    Sources and supporting references

    These are some of the works, studies and institutions used as conceptual support for the article's arguments.

    Keep the conversation going

    Want to take this conversation into a real project?

    If this reflection touches something relevant to your current moment, I can help turn context, vision and needs into a well-shaped project.

    More writing from the blog to expand the conversation between technology, process, market and real experience.