Grit: Rewriting Git in Rust with agents

Original Article ↗ Hacker News Discussion ↗

Motivation and Claimed Goals

  • Project is a from-scratch Rust implementation of Git, driven largely by LLM “agents.”
  • Core stated goal: a feature-complete, reentrant, linkable Git library (especially networking/credentials) for tools like Git-based GUIs and alternative VCS frontends.
  • Emphasis that it is not meant to replace canonical Git as a CLI, but to serve as a library where Git/libgit2/gitoxide are incomplete or not suitable.

Technical Status and Comparison

  • Reported to pass ~99.3% of the upstream Git test suite; remaining tests are explicitly skipped (email, i18n, SVN/Perforce importers, some bitmap/midx, etc.).
  • Acknowledged by its own author as currently slower, heavier, less scalable, and likely buggy vs Git; canonical Git is said to be better in all ways except “being a linkable library.”
  • Binary is much larger than Git’s, largely due to Rust ecosystem (CLI parsing, dependencies). Library subset is smaller but still non-trivial.
  • Compared repeatedly to gitoxide and libgit2, both of which already provide libraries but lack full feature/networking parity.

Use Cases and Interest

  • Potential uses: embedded Git networking/credentials in Rust apps, custom Git servers/clients, WASM builds for browser/edge environments.
  • Some see it as an interesting experiment or proof-of-concept for “agentic” development and large-scale LLM-assisted ports.
  • Others question whether any practical niche exists beyond what extending gitoxide/libgit2 could achieve.

Cost, ROI, and Practicality

  • Token spend estimated around $8k–$15k.
  • Many commenters view this as poor ROI: slow, incomplete, unproven tool vs a battle-tested Git, with existing Rust alternatives.
  • Some argue it mainly demonstrates that AI can “make tests pass” without proving robustness in real-world usage.

Licensing, Copyright, and Ethics

  • Major controversy: original Git is GPL; this project is released under MIT.
  • LLM agents were given Git’s source and tests as “source of truth,” not just black-box behavior. Critics call this plagiarism, “license washing,” or “Rustwashing” of a copyleft codebase.
  • Long, mixed legal debate:
    • One side: reimplementation in Rust with different structure, plus low similarity metrics, means it’s not a derivative work; using GPL tests as a behavioral spec is allowed; GPL doesn’t automatically infect independent implementations.
    • Other side: feeding GPL code directly to an LLM and asking for a functionally equivalent implementation is akin to translation/adaptation, so the result should inherit GPL; LLM is treated as a transformation tool like a compiler/transpiler, not a magical license eraser.
    • Additional arguments about whether test suites themselves can make outputs derivative, and whether outputs of LLMs are copyrightable at all.
  • Ethically, many see this as undermining the intent of the GPL and extracting community value into a permissive, more corporate-friendly license, even if it might be legally arguable.

Rust Rewrites and LLM Use

  • Broader frustration with “rewrite in Rust” culture, especially of GPL projects into MIT/Apache.
  • Some see Rust as valuable for memory safety in critical infrastructure (e.g., Git, nginx); others argue the main problems are logic, not memory, and that AI-driven rewrites may introduce worse bugs than they remove.
  • Strong pushback against “vibecoded” or “slop” LLM-generated code in security-sensitive components.
  • A few express enthusiasm for the experimental, agentic approach and for using LLMs to drive ports, but many feel the novelty has worn off and such projects now need clear, user-facing benefits.

Alternative Approaches Proposed

  • Instead of a wholesale rewrite:
    • Extend gitoxide or libgit2, especially networking/credentials, possibly with targeted LLM assistance.
    • First extract and formalize a behavioral spec from Git’s code/tests/docs, then reimplement from that “contract” to avoid test-hacking and reduce cost.
    • Focus on new tools or abstractions on top of Git’s storage model rather than cloning its entire implementation.