Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grit: Rewriting Git in Rust with agents

blog.gitbutler.com

Post reply on HN
Print view View original

31–40 of 318 posts

Re: Grit: Rewriting Git in Rust with agents

#31

Post by Aperocky »

Levitating wrote: post #27
Aperocky wrote: post #26

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

You cut that citation conveniently short. > 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.

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.

Re: Grit: Rewriting Git in Rust with agents

#33

Post by gpm »

nextaccountic wrote: post #20
Philpax wrote: post #11

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

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

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.

Re: Grit: Rewriting Git in Rust with agents

#34

Post by ianm218 »

jabwd wrote: post #30
ianm218 wrote: post #23

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

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?

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.

Re: Grit: Rewriting Git in Rust with agents

#35

Post by gpm »

fg137 wrote: post #9

Does anyone plan to use this? Similarly, is there any momentum left for Cloudflare's EmDash? I can barely find any discussion after April.

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.

Re: Grit: Rewriting Git in Rust with agents

#36

Post by gpm »

rvz wrote: post #2

> 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 n…

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

Re: Grit: Rewriting Git in Rust with agents

#38

Post by jauntywundrkind »

boredatoms wrote: post #29

Theres already git-in-rust project that is making good progress https://github.com/gitoxidelabs/gitoxide

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.

Re: Grit: Rewriting Git in Rust with agents

#39

Post by jabwd »

ianm218 wrote: post #34
jabwd wrote: post #30

Earlier quoted context omitted.

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?

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…

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

Re: Grit: Rewriting Git in Rust with agents

#40

Post by jauntywundrkind »

jabwd wrote: post #30
ianm218 wrote: post #23

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

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?

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.
Post reply on HN