Live data from Hacker News

Grit: Rewriting Git in Rust with agents

blog.gitbutler.com

171–180 of 318 posts

Re: Grit: Rewriting Git in Rust with agents

#171
post #32

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.

GitButler's source code is available, so we're not asking you to trust us much at all.

https://github.com/gitbutlerapp/gitbutler

Re: Grit: Rewriting Git in Rust with agents

#172

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.

This looks more like a blog-blurb (if blogs had blurbs) than a comment.

Re: Grit: Rewriting Git in Rust with agents

#173
post #127

Earlier quoted context omitted.

If feeding the source code through a complier yields a derivative work, why wouldn't feeding it to an LLM give the same result?

Because compilers and LLMs do different things, and what is done matters, so you can't reason by stepping from one to the other. Compilers don't axiomatically yield derivative works, they simply in practice do because for non-trivial programs they preserve copyrightable elements of the work in the output.

So, if we will compile or decompile code using LLM instead of a compiler, then we can use the result for free?

(LLM can translate code to/from other code or to/from a machine code).

Re: Grit: Rewriting Git in Rust with agents

#174
post #144

Earlier quoted context omitted.

Knowing what you don't know is such an important skill in life and your career. And I 100% agree with you that the author is, well, off their rocker. Let me give an example: I could take Goldeneye from the N64, extract the binary and then run it through an LLM to disassemble it and possibly rewrite it in a modern higher-level language. Do you think Nintendo would look at that and say "well, he did a lot of work so he…

Well that is already how it is done with numerous multi-decade open rewrites of closed games. They usually require the asset pack. I don't know how this squares with law, but Oracle v Google gave a very valuable judgment to the public that an API is not copywritable. If we take the LLM out of it, that's all we are talking about in the pure case. Of course, we can't take the LLM out, but it is the starting point.

> Well that is already how it is done with numerous multi-decade open rewrites of closed games

Serious such rewrites don't start with the code of the closed game!

> I don't know how this squares with law, but Oracle v Google gave a very valuable judgment to the public that an API is not copywritable. If we take the LLM out of it, that's all we are talking about in the pure case.

Not at all. The LLM used to write grit has seen the git code. That is what we're talking about here.

> Of course, we can't take the LLM out, but it is the starting point.

The LLM isn't the important thing. The important thing is that the git source code was used to make grit.

Re: Grit: Rewriting Git in Rust with agents

#175

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'm terrified that this somehow seems acceptable to a large group of people.

I'm baffled that other IP holders (say those who own valuable pieces of proprietary software, or music, or movies, or even the LLMs themselves) don't think leopards will come eat their faces next. This erosion of IP has to stop, or anyone who does any intellectual work will be absolutely screwed. If that only meant FOSS people, I'd be worried that we'd just be thrown out with the bathwater – but surely this applies across the board!?

Re: Grit: Rewriting Git in Rust with agents

#176

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

Yet, you didn't write the code yourself.

On Gitoxide: Given that the author read the docs and source code [0], and literally copied files over from the git source [1], it also is license-washing. At least libgit2 is GPLv2 with a linking exception. I don't think people would have much to say if these projects honored the original projects' intents and kept a copyleft GPL license. But they don't.

> The approach needed to make this a reentrant, memory safe, library driven codebase is so different that copying is generally not useful.

This is obvious given how different Rust is from most languages. So are licenses pointless as a concept now, because anyone can argue their Rust implementation of a GPL (or whatever) project is meaningfully different? Nice loophole there.

Stripping away the GPL in favor of MIT/ASL2.0 seems to be the trend for rust projects (see uutils, etc). I'm really glad that we can make it easier for large companies to extract value from community labor and, in general, not contribute much of anything back.

0: https://github.com/GitoxideLabs/gitoxide/discussions/253

1: https://github.com/GitoxideLabs/gitoxide/issues/925

Re: Grit: Rewriting Git in Rust with agents

#177
post #144
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.

Knowing what you don't know is such an important skill in life and your career. And I 100% agree with you that the author is, well, off their rocker. Let me give an example: I could take Goldeneye from the N64, extract the binary and then run it through an LLM to disassemble it and possibly rewrite it in a modern higher-level language. Do you think Nintendo would look at that and say "well, he did a lot of work so he…

> Knowing what you don't know is such an important skill in life and your career. And I 100% agree with you that the author is, well, off their rocker.

They aren't the only ones - look at the number of people in this thread who are arguing that this is analogous to producing a movie with ffmpeg - just because ffmpeg is GPL, does not make your movie GPL.

I am struggling to understand how such a high level of cognitive dissonance is possible: They believe both a) that the license can be laundered in this manner, and that b) the license they put on the result is effective!

Re: Grit: Rewriting Git in Rust with agents

#178
post #99

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…

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

I’m going out on a limb here but I’ll say that you are over engineering for the wrong problems. I’ve done it before, I tried libgit for some use case. At the end of the day it really is much simpler to use git. If you don’t want git at runtime use something like the git-gradle-properties plugin or the likes for your build system of choice. I really can’t think of a super duper use case where forking processes is a massive enough issue that I’d want to instead port over all of git to another language. Git for the most parts also offers a wide variety of export formats such that you get machine readable output too. If you really really need to fiddle with its internals, git pack lets you browse through the index fairly well. Again, my humble opinion, but you’re trying to solve the wrong problems

Re: Grit: Rewriting Git in Rust with agents

#179

Earlier quoted context omitted.

[flagged]

When we go a full year without a lpe in the linux kernel I'll start considering it...

How many of the LPE would rust even fix? They mostly seem logical errors and not memory or threading related race conditions to me.

Re: Grit: Rewriting Git in Rust with agents

#180
post #166
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…

> translation.

It's not technically a translation, it's a re-implementation, with test suites acting as the destination. If it was a file by file translation your argument would have been valid.

Post reply on HN