Grit: Rewriting Git in Rust with agents

Original Article ↗ Hacker News Discussion ↗

A new Rust-based reimplementation of Git, called Grit, claims to pass over 99% of Git’s own test suite and is being positioned as a linkable, memory-safe library for tools that currently must shell out to the Git CLI. Commenters question the practical value of duplicating Git—especially given Grit’s current slowness, incomplete test coverage, and overlap with existing efforts like gitoxide—and are sharply critical of the project’s use of AI agents and its decision to relicense behavior derived from GPL‑licensed Git under MIT. The debate centers on whether this constitutes ethically dubious “license washing” or a legitimate clean-room style reimplementation that could ultimately benefit the broader Git ecosystem, particularly for embedding and WASM use cases.

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.