Grit: Rewriting Git in Rust with agents
cbrewster
113 points
158 comments
June 09, 2026
Related Discussions
Found 5 related stories in 107.2ms across 10,002 title embeddings via pgvector HNSW
- Show HN: Gitdot – a better GitHub. Open-source, written in Rust baepaul · 206 pts · June 08, 2026 · 60% similar
- Show HN: Git for AI Agents doshay · 97 pts · May 08, 2026 · 58% similar
- Show HN: GitAgent – An open standard that turns any Git repo into an AI agent sivasurend · 108 pts · March 14, 2026 · 57% similar
- Zerostack – A Unix-inspired coding agent written in pure Rust gidellav · 285 pts · May 16, 2026 · 56% similar
- Show HN: Nit – I rebuilt Git in Zig to save AI agents 71% on tokens fielding · 20 pts · March 26, 2026 · 55% similar
Discussion Highlights (20 comments)
rvz
> the result is Grit, a from-scratch, library-based, memory-safe, idiomatic Rust reimplentation of Git that passes over 99% of the entire Git test suite. Why not 100%? > It's not actually passing every single test, though that is on purpose. I did mark some parts of the testing suite as "skipped" because I don't think it's worth recreating them in a library like this > 41,715 / 42,001 tests passing (99.3%) So it is not entire then but somehow that was worth burning $8,000~ dollars worth of tokens?
tonymet
they still haven't explained why I should bother. Is it faster, easier, more efficient, more capable, more scalable on large codebases, supports better workflows? In fact, I would rather it stay C for 15 more years.
heyts
I'd be really interested in the opposite, just for the sake of experimentation since that's what these projects mostly are. They all seem to be rewrites for the sake of "performance", because the cost is now lower bc of AI. I'd be interested to see something like a port of Quake III in Python or Kubernetes in Perl, even Rails in Python would be goofy and really fun to see
fg137
Does anyone plan to use this? Similarly, is there any momentum left for Cloudflare's EmDash? I can barely find any discussion after April.
Philpax
> In looking at the code that the LLMs have produced for the project, especially given the pretty massive and widespread architectural changes needed to make the implementation libified and memory safe, we decided that the codebase is not a derivative work that would require carrying forward the GPL license and have decided to release the code under the MIT instead. Hmm. That's going to be interesting.
gdgghhhhh
So, they "decided" it's not a derivative and thus can be listened under MIT instead of GPL....
imoverclocked
What’s the long term strategy for this code base? Does the author expect community code contribution or just bug reports or maybe just test contributions?
ianm218
I have been working on the same problem in other areas. My ultimate goal is to rewrite nginx in Rust passing as much as the upstream tests as possible while leveraging the strongest aspects of Ruts ecosystem - i.e. rustls (modern memory safe OpenSSL), Tokio (async runtime), h2 (http 2 impl) rather than implementing from scratch like the upstream. I started with Lua, then porting over Valkey, and now working on nginx. The reason was because I wanted to learn the ins and outs before taking on the most complex portion. [1]. https://github.com/ianm199/lua-rs/tree/main Lua [2]. https://github.com/ianm199/valdr Valkey/ Redis [3]. https://github.com/ianm199/nginx-rs-port nginx Happy to answer any questions on the approach! When I started a few weeks ago the harnesses on their own were not good enough to get very far without a "meta harness" of sorts but that is changing largely with Claude Workloads and Mythos. A lot of the work is developing some custom tooling to move these along faster.
dabedee
This is coming from a cofounder at github, someone who probably knows precisely what the GPL is for. Whatever the legal merits, building on a GPL3 project's complete test suite and relicensing under MIT is not acting in good faith toward the original authors. I really find it disgusting and it makes me want to avoid gitbutler entirely.
Aperocky
> A pretty fun experiment and I think we can shape this into something truly useful to the whole community. Agree with first half of this sentence, we should all have fun with experiments. > It was never based on a linkable and reentrant library, but instead on a "Unix" philosophy of chaining together simpler commands, which means that it's difficult to use it in long running processes without fork/exec overhead for everything. Ahhh now we have philosophical disagreement in the only place in the entire article that says "why". Unix is a feature, it's arguably more important in current time: https://aperocky.com/blog/post.html?slug=unix-philosophy-age...
boredatoms
Theres already git-in-rust project that is making good progress https://github.com/gitoxidelabs/gitoxide
dabedee
You're asking people to trust you and hand their codebase/IP to your tool while showing them exactly how you treat other people's code/licenses by "deciding" to not carry forward the GPL license.
ewy1
pretty dystopian to ask a robot to recreate your favorite software just so you can relicense it for your business venture
squidsoup
I guess software licenses are meaningless now since anyone can decide their llm clone is not derivative.
anonova
Grit was the name of a _Ruby_ implementation of git way back when: https://github.com/mojombo/grit/ . I believe it's actually what GitHub was built on then.
stefanha
> The full build of all Git functionality in Rust is currently around 27M, but since a large part of it is a library, it could clearly be easily split up into domains of functionality - subcrates that do specific things. I downloaded v0.3.99 for Linux x86_64 and stripped the binary. It ends up at 31 MB. The .text section is 25 MB. I'm surprised by the large size. On my system /usr/bin/git is 4.7 MB, although git is split up into multiple programs. I'm not comparing apples to apples, but this is weird. If anyone digs into the binary size, please share what you find.
hankbond
> It's like giving wishes as a genie. You gotta be super explicit with the ground rules. I have used the genie analogy before. It used to feel more like a Golem but now with the whole Fable sabotage mode https://jonready.com/blog/posts/claude-fable5-is-allowed-to-... it certainly feels more Genie-like. Previously I described it as "Models give you what you ask, for not what you want". Now with Fable they don't even give you want you want so idk.
usernametaken29
I’m all for memory safety and such but honestly what’s the use case for this? Showing off agentic development? In 10+ years git has never failed on a memory overflow or else. Sometimes software is “good as is” and I’m pretty confident git classifies as such. I’ve also never really hit the limitations of git, even with teams of 20+ developers and lots of binary artefacts. You got to really stretch git limitations, in which case you might need to move away from git, and a rust rewrite will not help in any way whatsoever. So again … why?
djha-skin
In the age of AI, writing things that used to take years can now be done in months or weeks if you have deep enough pockets for it. Reimplementation is a particularly juicy target because it's easy to test. Imagine someone writing a better browser than Chrome from scratch in just a year. Because of this moats around business due to difficulty of implementation are effectively gone.
aeon_ai
I continue to be surprised by the lack of understanding around copyright law when it comes to AI.