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

161–170 of 318 posts

Re: Grit: Rewriting Git in Rust with agents

#161

Post by rockmeamedee »

I don’t understand. Gitoxide exists and is great.

It might have missing pieces, but it’s easier to vibecode any needed networking additions to Gitoxide (which is maintained) than to just go and burn tokens trying to clone all of git again.

Git wants to add Rust. Gitoxide is a multi year project that’s going to be more maintained than an ad-hoc “it says it passes the test” vibeclone.

I’m not even against vibecloning things when it’s useful, but this shows no benefits. Git is a beloved tool that few people dislike, it’s not like vinext (people disliking the vendor lock-in they have with nextjs).

Also execs should keep in mind that “we burned thousands of dollars on tokens to re-create this beloved software so we can have our own copy”, even without the copyright/licensing argument, just isn’t something positive that the community will react positively to.

It doesn’t feel nice to see your favourite works cloned for no benefit. We’re past the “it was an experiment to see how far AI can go” stage now.

Re: Grit: Rewriting Git in Rust with agents

#162

Post by GreenDolphinSys »

This is simply plagiarism of GPL-licensed code, and license-washing as well. I can understand working backwards from a test suite, but this literally just reads the original source:

https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou...

LLM users seem to live in another world where stealing everything that isn't bolted down, and passing it off as their own work, is acceptable.

Re: Grit: Rewriting Git in Rust with agents

#163

Post by andwur »

schacon wrote: post #104
stefanha wrote: post #50

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

I would also be interested. I haven't dug into this at all yet, nor have I tried to optimize the size (or really, anything else). However, the library part will be less than half of this - a lot of code is spent on the CLI specific stuff and would not be part of the library, which is mostly what I care about for the purposes of this project. The CLI part is just to try to prove the point that it actually does what Gi…

Looking at just the `grit` executable, 58 of the top 200 largest file->resulting code sources are from clap-rs' derive functionality i.e. it's the command-line parsing. The #1 largest is, surprisingly, merge_trees[1] which comes in at 183kiB final binary size. There isn't so much code in that file that it seems reasonable, so it's potentially one of the derives in use (Debug being a common culprit for bloat) that's blowing it out. After those outliers it starts to level out quickly.

Splitting it by crate: `grit` is 13.6MiB, `grit_lib` is 4.8MiB and then it's `std`, `rustls` and `regex_automata` that are the next largest. So as pure library you could hopefully shave off quite a bit of that 25MiB.

[1] https://github.com/gitbutlerapp/grit/blob/main/grit-lib/src/...

Re: Grit: Rewriting Git in Rust with agents

#164

Post by bitwize »

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?

Because C code in production is a ticking time bomb.

Re: Grit: Rewriting Git in Rust with agents

#165

Post by schacon »

GreenDolphinSys wrote: post #162

This is simply plagiarism of GPL-licensed code, and license-washing as well. I can understand working backwards from a test suite, but this literally just reads the original source: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou... LLM users seem to live in another world where stealing everything that isn't bolted down, and passing it off as their own work, is acceptable.

I see it differently. I look at it as if I had written this code myself, using this same approach. Look at the docs, look at the tests, look at the source, implement something that is interactively compatible but a very different approach.

For example, this is exactly what I did when I tried to get SSH commit signing working properly in GitButler:

https://blog.gitbutler.com/signing-commits-in-git-explained

You can see in the post that I dug through the C source to figure out how it was canonically done and then implemented something that accomplished the same thing in Rust but without copying source code.

There are some similarities between the Grit Rust source and the Git source, but it's mostly around time/formatting type things or byte offset type things needed to make packfile parsing and whatnot work, but as far as I can tell, there is no straightforward copying of code. The approach needed to make this a reentrant, memory safe, library driven codebase is so different that copying is generally not useful. But nobody can _guess_ how packfiles or reftable binary formats are specified, since they're not really documented. I'm aware of this because I'm pretty sure I _personally_ am one of the only ones who has ever attempted to document the packfile binary format: https://schacon.github.io/gitbook/7_the_packfile.html

You have to read the source. Which means that libgit2 and Gitoxide and every other Git reimplementation is also "license-washing" per this definition because they also had to reference the Git source to see what the technical specification is.

If you find any code in Grit that is clearly line-for-line copied, please point it out and I will replace it. But the Git source is the Git specification and every reimplementation, LLM or not, is forced to use this approach to build anything compatible.

Re: Grit: Rewriting Git in Rust with agents

#166

Post by jbotz »

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.

A translation of a book to a different language is a derivative work. So a translation of a computer program to a different programming language is also. But if in the translation of the book you start altering the plot and the personalities of that characters, does it at some point become not a derivative work? What point? IANAL, and I have no real idea, but I imagine that point has been probed significantly in case-law with respect to creative works. Given the current climate of ever-expanding scope of "intellectual property", if they admit that the LLM had access to git source code then I would say their case is weak at best.

Re: Grit: Rewriting Git in Rust with agents

#167

Post by dochtman »

rockmeamedee wrote: post #161

I don’t understand. Gitoxide exists and is great. It might have missing pieces, but it’s easier to vibecode any needed networking additions to Gitoxide (which is maintained) than to just go and burn tokens trying to clone all of git again. Git wants to add Rust. Gitoxide is a multi year project that’s going to be more maintained than an ad-hoc “it says it passes the test” vibeclone. I’m not even against vibecloning t…

GitButler now employs/has hired the gitoxide maintainer, I think? So no doubt they’re aware.

I guess they found that gitoxide isn’t good enough and/or to expensive to extend/improve for their use cases?

Re: Grit: Rewriting Git in Rust with agents

#168

Post by schacon »

dochtman wrote: post #167
rockmeamedee wrote: post #161

I don’t understand. Gitoxide exists and is great. It might have missing pieces, but it’s easier to vibecode any needed networking additions to Gitoxide (which is maintained) than to just go and burn tokens trying to clone all of git again. Git wants to add Rust. Gitoxide is a multi year project that’s going to be more maintained than an ad-hoc “it says it passes the test” vibeclone. I’m not even against vibecloning t…

GitButler now employs/has hired the gitoxide maintainer, I think? So no doubt they’re aware. I guess they found that gitoxide isn’t good enough and/or to expensive to extend/improve for their use cases?

I think Byron (Gix author/maintainer) is one of the most excited people about the Grit project.

Gitoxide is great and we will continue to push it forward. Grit is an orthogonal project. Perhaps we can use one in the other or maybe Grit goes nowhere. But we thought that a small investment in a different approach is worth the effort.

Re: Grit: Rewriting Git in Rust with agents

#169

Post by schacon »

rockmeamedee wrote: post #161

I don’t understand. Gitoxide exists and is great. It might have missing pieces, but it’s easier to vibecode any needed networking additions to Gitoxide (which is maintained) than to just go and burn tokens trying to clone all of git again. Git wants to add Rust. Gitoxide is a multi year project that’s going to be more maintained than an ad-hoc “it says it passes the test” vibeclone. I’m not even against vibecloning t…

As mentioned, we also work on the Gitoxide project and Byron is a member of our team. We are well aware of all large community efforts and we're also cohosting the Git Merge conference this year.

There is a recent effort to vibe-loop more Git into Gitoxide, which is interesting:

https://github.com/GitoxideLabs/gitoxide/pull/2538

I still think that this is a project that can have value with a little more work. This announcement is merely a milestone, not the end product. I wasn't sure it was really possible to do, even halfway through the project. There has been a lot learned and there is a lot to learn, but I think there are useful applications for both a high quality, hand crafted, opinionated partial Git library (Gix) as well as a vibed, fully implemented, partially sloppy LLM Git library (Grit). We think it's worth exploring and investing in both options for now.

Also, I am the exec involved and I've done quite a lot for the Git community over the years. I would never try to have my "own copy" of it, that's ridiculous. I wrote and open sourced the Pro Git book (https://git-scm.com/book/en/v2) and Git community book before it (https://schacon.github.io/gitbook/index.html), I created the official Git website (https://git-scm.com), I cofounded GitHub which hosts nearly all open source in the world, I have evangelized and supported the Git ecosystem for almost 20 years now. I restarted and funded development of libgit2 15 years ago, which you could similarly argue was an exec trying to have our "own copy" of Git under a more permissive license and would have been a similarly ridiculous argument.

Post reply on HN