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

91–100 of 318 posts

Re: Grit: Rewriting Git in Rust with agents

#91

Post by joshka »

joshka wrote: post #79
trumpdong wrote: post #71

Earlier quoted context omitted.

Asking an LLM "here's a thing, rewrite it in Rust" is pretty clearly creating either a derivative work or a different form of the same work, just like asking a transpiler would.

There's no evidence that "here's a thing, rewrite it in Rust" is the technique Scott used here. "here's a test suite, write code in rust that makes that suite pass" is reasonably supported by the article. That would likely not be a derivative work.

It's actually murkier than I suggest here. https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou...

Re: Grit: Rewriting Git in Rust with agents

#92

Post by ianm218 »

uecker wrote: post #77
ianm218 wrote: post #67

Earlier quoted context omitted.

https://securityaffairs.com/192132/hacking/nginx-rift-an-18-... The project was inspired by that. Also unlike most other projects, nginx is directly exposed to the internet often times which makes it more vulnerable than i.e. Redis/ Valkey or something that would be running within a companies network generally. "C Bad" is a bit reductionist... but I think there is some truth to the take " Until you have the evidence,…

I think the risks of a rewrite - especially when using AI - are far more problematic than memory safety. In the long run those C projects will be memory safe in the next five years using memory safe C implementations.

My perspective is that it is good to have a beta in a lot of directions.

No one really knows what the endgame of software security looks like.

So some people should try the port to rust angle, some should focus on hardening the C, some should explore more exotic options like formally provable languages etc

Re: Grit: Rewriting Git in Rust with agents

#93

Post by Ferret7446 »

MBCook wrote: post #53
heyts wrote: post #6

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

> They all seem to be rewrites for the sake of "performance". And yet this performs dramatically worse. A slower, untested, incomplete git implementation, all for the low low price of $10-$15,000. And don’t forget it wasted a bunch of human time in the process. So if someone mentioned somewhere else there is already a Rust port a group is doing somewhere. How much could they have accomplished with this much money and…

It's not for performance, it's for Rust.

If the first stereotype of Rust programmers is announcing that a project is in Rust before any other desirable software property (e.g. stable, performant, etc), the second stereotype is that Rust programmers love rewriting stuff in Rust, just for the sake of Rust.

(The 2.a. corollary is that they love rewriting GPL projects specifically and downgrading them to MIT/Apache)

Re: Grit: Rewriting Git in Rust with agents

#94

Post by joshka »

MBCook wrote: post #89
joshka wrote: post #79

Earlier quoted context omitted.

There's no evidence that "here's a thing, rewrite it in Rust" is the technique Scott used here. "here's a test suite, write code in rust that makes that suite pass" is reasonably supported by the article. That would likely not be a derivative work.

If we assume an u licensed or MIT licensed test suite, an LLM could develop from that and documentation and you’d get something you could license MIT. IMO, IANAL, etc. And we’ll ignore the question of what the fact the LLM has certainly seen the git code during training means. But the test suite would have to stay under the original license. And if you use a GPL test suite as they kernel to develop a program from can…

This is the exact thing I'm not sure about. See https://news.ycombinator.com/item?id=48470397 where I posit a simpler question: if a `test_sum()` function is copyrighted, does writing a `sum(a, b)` function infringe on the copyright of the software product that `test_sum()` is a part of. I'd say no. There's another part of the GPL that applies here:

> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

So assuming that sum(a, b) is non-infringing and not combined to form a larger program (i.e. the tests aren't compiled into the grit code), then the GPL explicitly doesn't apply to this use

Re: Grit: Rewriting Git in Rust with agents

#95

Post by WD-42 »

usernametaken29 wrote: post #78

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…

License washing

Re: Grit: Rewriting Git in Rust with agents

#96

Post by gpm »

joshka wrote: post #90
gpm wrote: post #84

Earlier quoted context omitted.

> using the git test suite That's not actually the case at hand here - the agents were given the original source to reference: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou... But for the sake of argument: The test suite itself is copyrighted. To the extent the resulting work is a derivative of the test suite it is possibly infringing. For example you might example that the agent would derive variable…

> That's not actually the case at hand here - the agents were given the original source to reference: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou ... yeah fair - the "The canonical Git source code we're targeting to replicate the functionality of is in the git/ subdirectory." part makes this hard to argue against. > To the extent the resulting work is a derivative of the test suite it is possibly inf…

Writing

    fn sum(a: u8, b: u8) {
        a + b
    }
Doesn't infringe upon copyright period, because there's no creative element in that work.

Imagine a more substantial example though. Perhaps you have a test that checks that some file written in a binary format is correct, and gives names (creative elements) to each field of the format that it prints when you mess up the field, and has comments describing why the bytes are laid out like they are (the comments being copyrightable even if the facts they describe aren't), and the LLM copies those field names and comments verbatim... Now it's quite likely that the LLMs work is a derivative of the test suite.

Re: Grit: Rewriting Git in Rust with agents

#97

Post by gpm »

trumpdong wrote: post #88
gpm wrote: post #86

Earlier quoted context omitted.

Yes... and now we get to the fact specific question of "did they copy the program". Or actually the answer to that is plainly "no" - they made something similar from it - and didn't run ctrl-c ctrl-v in an unlicensed manner, but "did they copy the relevant facets of the program into the new similar thing".

Making something similar is copying for the purpose of copyright law. If I trace over a Disney character it's still copyright Disney.

No. You're allowed to make a similar tool, the functional elements are not copyrightable. There's a long history, predating LLMs by many decades, of doing this in the software industry.

My use of the word "similar" does not imply here that I think it's obvious that they are "similar" in any copyrightable elements - whether they are or not is one of the interesting questions I think this case would have to resolve.

Incidentally you're also allowed to make similar creative elements so long as they aren't copies and you did so independently... which could actually come up in a case like this (imagine the LLM produced a similar function to some function in the original... but the original wasn't in the context window at the time. Not at all unlikely with code where there often is only one or two natural ways to write something).

Re: Grit: Rewriting Git in Rust with agents

#98

Post by MBCook »

joshka wrote: post #94
MBCook wrote: post #89

Earlier quoted context omitted.

If we assume an u licensed or MIT licensed test suite, an LLM could develop from that and documentation and you’d get something you could license MIT. IMO, IANAL, etc. And we’ll ignore the question of what the fact the LLM has certainly seen the git code during training means. But the test suite would have to stay under the original license. And if you use a GPL test suite as they kernel to develop a program from can…

This is the exact thing I'm not sure about. See https://news.ycombinator.com/item?id=48470397 where I posit a simpler question: if a `test_sum()` function is copyrighted, does writing a `sum(a, b)` function infringe on the copyright of the software product that `test_sum()` is a part of. I'd say no. There's another part of the GPL that applies here: > A compilation of a covered work with other separate and independen…

test_sum is assumedly relatively trivial. So as a lay person I’d expect some sort of obviousness test to apply. Like so much of the stuff in the Google/Oracle lawsuit.

But if you take all the individual tests used to test git as a whole, that seems far more unique. Seems like at that point you’re really having to duplicate the actual git internals, and that seems like it should be covered.

Re: Grit: Rewriting Git in Rust with agents

#99

Post by schacon »

usernametaken29 wrote: post #78

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…

I addressed this in the post, but Git has no linkable library and never has. If you want to do even something small, you need to fork/exec a process and communicate with it via stdin/out. Or completely reimplement it and all of the edge cases - for example, reading even one object can be either loose (easy) or in a packfile (much more difficult). Reading a reference (what SHA does a branch point to) can be in a loose file, a packfile, or a reftable. etc.

There is no way anyone would ever use this for it's CLI - it will almost certainly always be slower and worse in every way, even if I get it stable (which it's currently not). You can use libgit2 (a project I also helped kickstart), or Gitoxide (a project GitButler also currently helps drive) - they are faster and better in nearly every way, but they are not feature complete.

This isn't for the person using Git. This is for someone trying to build a tool that wants to use parts of Git, which is different.

Re: Grit: Rewriting Git in Rust with agents

#100

Post by MBCook »

joshka wrote: post #91
joshka wrote: post #79

Earlier quoted context omitted.

There's no evidence that "here's a thing, rewrite it in Rust" is the technique Scott used here. "here's a test suite, write code in rust that makes that suite pass" is reasonably supported by the article. That would likely not be a derivative work.

It's actually murkier than I suggest here. https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou...

Ew. So it tells the LLM where the git source is for the thing they’re duplicating, but I don’t see instructions saying not to read or copy those files or algorithms.

I could have missed them. I didn’t read everything. I did some quick searches.

But the fact they’re not obvious is kind of troubling. Or that they didn’t just copy the tests and documentation for the LLM and not the source to prevent it from looking would hurt any case they had for clean-room privileges in my eyes, ignoring my other comment with concerns about using the tests at all.

Post reply on HN