Grit, a Rust reimplementation of Git from GitHub cofounder Scott Chacon, passes 99% of Git's test suite. Its own author warns it isn't production ready, and the lasting story is the architectural one.
For 15 years, anyone who wanted to put Git inside another program has had the same problem: Git was never designed to be a library. Its architecture is a chain of small C commands that hand work to each other, a Unix-philosophy design that runs beautifully in a terminal and breaks down the moment you try to embed it in a long-running process.
Scott Chacon, a GitHub cofounder and now the head of GitButler, has spent a career around that constraint. His new project, Grit, is a from-scratch Rust reimplementation of Git that he says is designed to fix it. The project's own site describes a "library-first" core: a Rust crate that other programs can link against, with the ability to run multiple Git operations inside a single process, the property the current C Git lacks. A separate CLI binary sits on top and calls into that core.
The architectural shift is the point. Gitoxide, the other Rust Git implementation, also targets this problem, but Chacon characterizes it as having "partial, slow or non-existent" networking, which is why projects like Jujutsu and GitButler still shell out to a real Git binary. libgit2, the C library that started 15 years ago with the same ambition, has complex and partial networking and credential handling, in Chacon's reading. isomorphic-git covers the WASM case but only partially. Cloudflare's recent Artifacts: Git for agents is another WASM-shaped attempt at the same problem.
Chacon built Grit by orchestrating a swarm of coding agents against Git's own test suite as the specification, the same pattern Anthropic used to build a C compiler with agents earlier this year. The result, by his count: Grit passes over 99% of Git's test suite, a corpus of roughly 42,000 tests across 1,400 scripts. The whole codebase is safe Rust, except for one FFI module that wraps localtime_r, strftime, and mktime (the date and time functions that don't have clean Rust equivalents that respect timezones) and one terminal-capability check.
This is where the caveats have to sit, and they have to be loud. Chacon himself warns that Grit is "not tested" in the production sense: it has no Windows build, can be exponentially slow on some paths, and could corrupt your repository. He asks readers not to run it on anything real. A clean test pass on 99% of a comprehensive suite is meaningful, but it is not a guarantee of correctness on real-world repos with years of history, unusual refs, partial clones, or weird edge cases. The repository's own README is the place to look for the current state.
A handful of test categories are intentionally skipped rather than failed: email, internationalization, the importers that pull in history from Perforce and Subversion repositories, and some of the multi-pack-index and bitmap work (server-side optimizations for very large repos). Chacon frames these as out of scope for a library: email is a transport, i18n is presentation, the foreign VCS importers don't fit the model, and the bitmap work is a server-side optimization. A reader who needs any of those in their Git library will need to keep using real Git or another implementation.
The target use cases Chacon names are the embeddability story. GitButler and Jujutsu would like to push and fetch without forking a process. WASM builds could let Git run inside edge functions and in the browser as a more complete alternative to isomorphic-git. Editors could embed discrete Git operations directly, and so could agent desktop tools that need to read and write repos without spawning a process. None of that requires Grit to be a drop-in Git replacement, which it isn't.
The agent angle is the part that travels on social media, and Chacon is honest about the messy middle. The first attempt, "fire a loop of agents," failed. What worked was an iterative loop where agents proposed changes, the test suite graded them, and Chacon steered scope and architecture. The cost was high and the process was non-deterministic, by his own description. The Anthropic C-compiler experiment, which he cites as the spark, used the same test-suite-as-spec technique. That pattern works when a project has a real, comprehensive test corpus, the way Git and a C compiler both do. It tells you less about agents generally than it does about what a strong test harness can do for them.
What to watch: a real-world test on a non-trivial repo from outside the maintainer, an honest third-party benchmark against Gitoxide and libgit2 on the operations Grit claims to cover, a Windows build, and the first production embedding. GitButler shipping Grit as its in-process Git backend would be the cleanest signal. Until then, the right way to read Grit is as a proof that the embeddability problem is solvable, written by someone who has been stuck on it for 15 years, and explicitly not a replacement for the Git you already have.