Grit: Rewriting Git in Rust with Agents

Posted by cbrewster 4 hours ago

Comments

Comment by Philpax 1 hour ago

> 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.

Comment by nextaccountic 1 hour ago

they would be just wrong. I hope someone with standing sues

Comment by gpm 35 minutes ago

I don't think it's that clear cut. The functional parts probably aren't copyrightable, only the stylistic ones. It's going to be a mix of courts applying laws in new ways that hasn't been done before and fact specific questions about what actually persisted through the LLM if it goes to court.

I'd be fascinated to see what happens if it does. Both in the analyses that we'd get of what the LLM did to the codebase and on the legal decisions on what the copyrightable creative elements in code actually are.

If I was the author though... there would be no way that I would be volunteering to be a test case like this. Also seems just rude for no reason.

Comment by dabedee 40 minutes ago

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.

Comment by boredatoms 42 minutes ago

Theres already git-in-rust project that is making good progress

https://github.com/gitoxidelabs/gitoxide

Comment by jauntywundrkind 15 minutes ago

Gitoxide is mentioned in this write up, yes,

> Currently both Gitoxide and libgit2's networking functionality is either partial, slow or non-existant. Both GitButler and Jujutsu rely on forking out to Git in order to push or pull data. A big reason for this is the incredibly complicated credential logic involved, but all of this is (theoretically) currently covered in Grit.

Comment by squidsoup 8 minutes ago

I guess software licenses are meaningless now since anyone can decide their llm clone is not derivative.

Comment by heyts 1 hour ago

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

Comment by jamesfinlayson 1 hour ago

> Quake III in Python

Probably doable - I remember most of Natural Selection 2 was Lua and it's more than a decade old at this point.

Comment by gdgghhhhh 1 hour ago

So, they "decided" it's not a derivative and thus can be listened under MIT instead of GPL....

Comment by madeofpalk 1 hour ago

Yeah, that's usually how contracts work.

You decide whether you have followed it or not. The other party will decide if they agree. If in dispute, you go to a judge and they decide also.

Comment by subygan 1 hour ago

a lot of things are just "decided" really.

it's just in this case it's the author. we'll have to wait and see who decides to challenge it

Comment by ianm218 57 minutes ago

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.

Comment by jabwd 40 minutes ago

Yeah I got one, why? You aren't learning anything, you are just copying code from other codebases and smashing it together to make some nginx-rust thingie... for what actual goal?

Comment by ianm218 33 minutes ago

Well the biggest goal was to be useful. Nginx serves ~20% of the web, memory unsafe languages might just become untractable for critical exposed to the web infra if the rate of critical CVE's on these rises faster than they can be patched, so a drop in replacement would be a big deal in that world.

But in terms of learning I'm learning relatively little about how to type Rust into an editor but a lot about how to set up agentic loops that can autonomously get tests to pass and improve performance.

For example if you just tell a frontier model (gpt5.5 or Claude Code 4.8) to make some portion of the tests pass they will take forever and just bang their heads against it. I developed a framework to mimic a lot of these tests in nginx... but in minimum non blocking ways so you can run many in parallel with short feedback loops.

Similar for performance - how to make tons of performance benchmark and expose maximum telemetry for agents to go and analyze the hotpaths etc.

Comment by fvdessen 6 minutes ago

You mean you rewrote the nginx test suite with smaller leaner tests ? How did you bootstrap that ? How do you know the leaner tests are equivalent to the real ones ?

Comment by jabwd 15 minutes ago

Buddy, I think it is time to not engage with these models for a bit, you seem to have lost your mind.

Comment by ianm218 11 minutes ago

We're literally in a thread on converting legacy C projects to idiomatic Rust? It seems many people are working on this same problem.

Comment by jabwd 2 minutes ago

There are plenty of Rust based reverse proxies out there, why do you need to specifically rewrite nginx? You could also write a config adapter to Caddy, there are a billion options, but this is a wasted effort. The people who want to stick to their nginx configs won't use your project ever, and the people who actually care about security aren't going to use a vibe coded project.

I have no idea why you are making me spell this out, I thought it was pretty obvious.

Comment by jauntywundrkind 14 minutes ago

One very strong draw I feel, that's mentioned in this article: Rust's portability, it's ability to be compiled to wasm & run very well anywhere.

Comment by Aperocky 54 minutes ago

> 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...

Comment by Levitating 45 minutes ago

You cut that citation conveniently short.

Comment by Aperocky 40 minutes ago

Added it in full. It still squarely falls under "this is for fun/are you seriously doing this for this purpose" territory for me.

git operate on the filesystem level, the unix behavior is just getting buried. You cannot rewrite git into a linkable library and decide it's now not unix. It's entire behavior is unix, which is why it's awesome.

Comment by dabedee 54 minutes ago

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.

Comment by imoverclocked 1 hour ago

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?

Comment by Yokohiii 9 minutes ago

He will be probably super happy for starring the project.

Comment by fg137 1 hour ago

In 6 months, seeing no adoption, move the repo to maintenance mode. Archive in 12 months.

Comment by fg137 1 hour ago

Does anyone plan to use this?

Similarly, is there any momentum left for Cloudflare's EmDash? I can barely find any discussion after April.

Comment by gpm 25 minutes ago

It'd seem weird to plan to use this until the readme stops saying

> it has been nearly entirely written by agents and has not been used for realsies. It's probably currently unusably slow or completely broken in ways that are not exercised in the test suite.

Right now it's someone else's experiment that is still in the "might or might not pan out" stage.

There are a bunch of projects using the similar (not vibe coded, less fully featured) gitoxide project - there is demand for git-as-a-library.

Comment by ewy1 17 minutes ago

pretty dystopian to ask a robot to recreate your favorite software just so you can relicense it for your business venture

Comment by tonymet 1 hour ago

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.

Comment by huflungdung 1 hour ago

[dead]

Comment by rvz 1 hour ago

> 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%?

> 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?

Comment by gpm 22 minutes ago

> Why not 100%?

From the article

> 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 - email related stuff, i18n, perforce/svn importers, some of the midx/bitmap stuff - things of that nature. However, for everything that I'm sure is relevant to nearly anyone reading this, the Grit library/CLI can now fully pass the Git test suite.

Comment by ianm218 56 minutes ago

There is often good reasons for these purposeful digressions. I.e. in nginx the unit tests cover cyphers that are considered unsafe and not supported by modern libraries like rustls https://github.com/rustls/rustls. It is reasonable to make a new implementation and leave behind a bit of baggage.

Comment by insanitybit 1 hour ago

So .7% tests fail therefor it was 100% a waste of time?

Comment by fg137 1 hour ago

I think we are talking about ROI in terms of solving real world problems and making real impact, not the fact that a tool has been ported from language X to language Y.

Comment by Zopieux 1 hour ago

Regardless, what's the point?

Comment by sharkjacobs 1 hour ago

> One of the main things I would like to be able to use it for is to be able to bundle complex push/fetch functionality into GitButler and other standalone Git tools needing network functionality (such as Jujutsu).

> Having parts of Git as discrete, embeddable slices of library also enables things like building custom Git servers or client functionality in Rust.

> 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. Perhaps you could simply use the subset you need.

Comment by insanitybit 44 minutes ago

The article starts out with paragraphs about the history and motivation.

> it made me wonder about the feasibility of using that same approach to accomplish something I've been dreaming about for 15 years now,

> which means that it's difficult to use it in long running processes without fork/exec overhead for everything.

> What if we used the same basic idea that Anthropic used on their from-scratch C compiler? Start a brand new implementation, design it as a Rust library, then throw a swarm of agents at the problem

Comment by tonymet 1 hour ago

maybe it's an academic project. proof they could reimplement something useful & complex?

Comment by rvz 1 hour ago

Given the author already admitted that the implementation was slow anyway, you are no better off of using gitoxide instead and that has support for Windows where-as Grit does not.

Comment by sharkjacobs 1 hour ago

Comment by bryanlarsen 1 hour ago

It depends whether the 0.7% failures are testing deliberately unimplemented features like email or is in corner cases in implemented features. It sounds like it's at least mostly the former, hopefully it's 100% the former.

I don't care if any git I use has email features. IIUC, even most of the people that use git with email don't directly use the email features, they use the patch set features like `git am`. I expect `git am` to work, I don't expect git to actually do email.