Live data from Hacker News

Grit: Rewriting Git in Rust with agents

blog.gitbutler.com

241–250 of 318 posts

Re: Grit: Rewriting Git in Rust with agents

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

> Do you think Nintendo would look at that and say "well, he did a lot of work so he's escaped our license"? Of course not. It's just silly.

That's because you're re-using assets.

Re: Grit: Rewriting Git in Rust with agents

#243

Earlier quoted context omitted.

Well, there's lots of really interesting opinions here from a lot of armchair lawyers. To clarify, my stance on this is that the reimplementation did not copy protected expressions (Jplag reports less than 1.8% max similarity between the codebases), it's done in good faith, and it's what's best for the broader Git ecosystem (assuming Grit even becomes usable, which it's currently not purported to be). From a copyrigh…

Have you addressed anywhere why you chose not to keep the copyleft license? It burns a lot of goodwill to use an AI for what many people will see as copyright laundering, and git has done just fine with the GPL, so it doesn’t seem like a blocker for adoption. What do you get from stripping the copyleft?

https://blog.gitbutler.com/series-a likely has a large part to play in it.

By which I mean, what do we imagine a16z thinks of the [L]GPL?

My brief experience in a startup exposed to them is that a16z seems willing to fund "infrastructure" projects more than most, but they did seem to have a ready set of answers on what "open source" means in that context.

(If someone can find me an a16z funded team that published copylefted code, I'll take this back.)

EDIT: Ok, i'll eat my hat, Gemini found me some counterexamples

  Element (Matrix): The company behind the decentralized Matrix communication protocol is on a16z's investment list. In late 2023, Element relicensed its core software (including the Synapse server and its clients) to AGPLv3.

  Uniswap Labs: A massive cornerstone of the a16z Crypto portfolio. They published the Uniswap V2 smart contracts under GPL-3.0 (though they later shifted to a Business Source License for V3 and V4).

  a16z Themselves: In an ironic twist, a16z's own crypto engineering team maintains a public GitHub repository (a16z/a16z-contracts — a library for Solidity contracts) that is literally licensed under AGPL-3.0.

Re: Grit: Rewriting Git in Rust with agents

#244
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

[deleted]

Re: Grit: Rewriting Git in Rust with agents

#245

Is there a term yet for Rust projects rewriting GPL code to get it under non-gpl licenses? Rustwashing ?

What does rust have to do with it?

The pattern I see here is people vibing slop rewrites of GPL projects to get them under more favorable licenses. Rust just happens to be the language this one picked (for various reasons that are not very relevant here.)

Re: Grit: Rewriting Git in Rust with agents

#246
post #174

Earlier quoted context omitted.

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

>Serious such rewrites don't start with the code of the closed game! No, but they often involve reverse engineering the binary pretty heavily.

> No, but they often involve reverse engineering the binary pretty heavily.

… and those often end up in legally dubious situations.

Re: Grit: Rewriting Git in Rust with agents

#247

Earlier quoted context omitted.

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

I mean we’re almost there with Mythos/Fable so there ya go. In two years bye bye rust.

Did you create this account just to lament rust hype? I mean, it is excessive. But I also don't think it is manufactured. We are more like some mostly benign evangelical denomination trying to get everyone to see the joys of Ferris.

Re: Grit: Rewriting Git in Rust with agents

#248
I'm exhausted seeing this same mistake happen over and over and over. Why nobody tries to write a spec from existing code is just crazy to me.

The git test suite is a behavioral spec. But at the same time it is not, why? It's archaeological site... I'd say. You can dig, and dig, and dig, and find some truth, but also a lot of historical decisions that doesn't matter today.

Here's the flow I suggest:

- first, reverse-engineer the behavioral intent from tests/docs/code

- build a taxonomy of what git promises

- group that into small "conformance slices"

- hand those slices to agents/humans/whatever

- start writing Rust... Or Visual Basic... At this point it doesn't matter almost

Without this critical layer, agents are optimizing for "make this test green" instead of "preserve this semantic contract". And this is exactly where the funny stuff happens... shelling to real git, hardcoding expectations, implementing sha256 metadata but not the behavior, etc.

Why are we doing stupid things and winning stupid prizes? I have to admit they are impressive, but I STRONGLY believe if we did this in two passes you would have not $15k check but maybe closer to $1-5k.

Who should I talk to, to make this happen? Making the first pass is almost deterministic. LLMs help. The only problem is making sure that YOU understand the spec, and this will be a bottleneck for a while (i.e. can't outsource understanding).

I can guide what exactly needs to happen. I already validated this idea on my own project and it worked: 10k LoC -> 250 acceptance criteria. And you can find it on my GitHub, I even described steps. If you're too lazy here it is:

You need a SCIP graph. Agent goes over it and builds ledger, one symbol at a time, looks at what kind of problem this symbol solves. This leads you to v0 specs, then you can figure out taxonomy, then you try to fit all those thousands of specs into taxonomy / groups that make sense. And that would be v1 spec but you might want to refine it to v2/v3. And then the only thing would be left is figure out what kind of tests those specs should have (e2e/unit/integration/api/whatever). This is tricky part but doable. I'm thinking for git you wanna do e2e specs. Yes, that's a lot of e2e but the purpose is that we build same expectations for git, and then we replace git with grit and spec should still stay green, right?

Hope that makes sense.

Re: Grit: Rewriting Git in Rust with agents

#250

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?

I'm happy to take contributions if you want to throw some tokens at it. Bug reports would be amazing, since I haven't tested it for real very much (enough to know you can do basics). I want to get it to the point where we can replace fork/exec'ing to an unknown Git binary or having said binary be an external dependency for GitButler. The networking stuff (push/fetch) is currently an external dep for both GitButler an…

I won't touch relicensed code even if you payed me.

This is morally, if not legally, wrong.

Post reply on HN