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

151–160 of 318 posts

Re: Grit: Rewriting Git in Rust with agents

#151

Post by WD-42 »

Ar-Curunir wrote: post #142
thewebguyd wrote: post #139

Earlier quoted context omitted.

Not a fan of this trend of "cleaning" GPL licensed software and releasing under permissive licenses. Also why I'm not a fan of UUtils nor Canonical's early adoption of it in Ubuntu. The intent here is extraction of all the value provided by copyleft projects without the obligation to give back. Wether it's technically legal or not, it's disgusting behavior IMO.

That’s explicitly not what’s happening with uutils; they have contributed fixes and test cases back to upstream

And just like that, it was forked by Microsoft a few days ago. Handed to them on a silver platter.

Re: Grit: Rewriting Git in Rust with agents

#152

Post by vasachi »

joshka wrote: post #82
trumpdong wrote: post #72

Earlier quoted context omitted.

why wouldn't it? If you run git through a compiler it's still copyright the git devs, same if you run it through an LLM.

What makes you think that's what the article says that it did? There's a lot of specific nuance and it doesn't say that anywhere. In fact it speaks of making a test suite pass only. This is the classic cleanroom bios from specs approach but no need to extract it as the test is available to run and there's nothing in the GPL that suggests that running a test suite infects software that you run it on.

Surely git’s source is already in LLM’s training corpus. So this is far from clean room approach.

Re: Grit: Rewriting Git in Rust with agents

#153

Post by jraph »

djha-skin wrote: post #83

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.

> can now be done in months or weeks if you have deep enough pockets for it.

Especially if there's the same thing that already exists in open source that the model can plagiarize for you.

Re: Grit: Rewriting Git in Rust with agents

#154

Post by Daishiman »

dakolli wrote: post #136
dstanko wrote: post #129

In 15+ years of using Git, I have not had a single crash. What problem are you solving???

This is a problem with people with LLM psychosis who now think they have superpowers, they are completely unaware and just do things naively, they've lost all ability to think for themselves. The LLMs that are thinking for them certainly aren't going to tell them doing X is a bad idea, they're there to produce as many tokens as possible for their owners.

The motivation and rationale is there and was mentioned early on in the article.

I’m all for the hundreds of reasonable objections but this sort of trash mindless critique is as useless as what it denounces.

Re: Grit: Rewriting Git in Rust with agents

#155

Post by jraph »

WD-42 wrote: post #95
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

"Grift"

(The f is for "feft")

Re: Grit: Rewriting Git in Rust with agents

#156

Post by wongarsu »

nomel wrote: post #137
joshka wrote: post #57

Earlier quoted context omitted.

I suspect that the issue is more likely that the LLM code doesn't have an author and hence some parts of it can't be licenses, it's less likely that it's infringing on git's copyright for various reasons. (I am not a lawyer, but I do read copyright law for funsies).

https://www.copyright.gov/newsnet/2025/1060.html > It concludes that the outputs of generative AI can be protected by copyright only where a human author has determined sufficient expressive elements. This can include situations where a human-authored work is perceptible in an AI output, or a human makes creative arrangements or modifications of the output, but not the mere provision of prompts. Well that's interesti…

Also "just" the legal opinion of a government office. It has yet to be tested in court

Re: Grit: Rewriting Git in Rust with agents

#157

Post by gritzko »

schacon wrote: post #99
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…

Nice experiment, but a bit expensive.

I work on Beagle, a git-compatible SCM [1]. I use ABC, Abstractionless C [2] dialect with slices, optional range checking, etc. So far, memory safety was the least of my concerns, frankly. Most of the thorny issues would be equally thorny in Rust (e.g. right now: reflog zeroed when VM ran out of disk space; must be some state machine issue or an OS level glitch). Also, forking off a C process (no runtime) is cheap enough that you actually want to do that more.

But, those are all technicalities. The key issue I see with the approach: the data structures and algos of git have been fanatically fine tuned for that particular application with those particular usage patterns. By very sophisticated low-level C programmers. So, quite likely, any other app/lib working with that store will always be a suboptimal fit. I would recommend read-only access only, esp for LLM code.

Meanwhile, git's underlying data model (blobs/trees/commits) is very simple and very much internet-standard level. Decoupling at that interface is so much easier with so much less issues looming.

May look differently from your vantage point though.

[1]: https://github.com/gritzko/beagle

[2]: https://replicated.wiki/blog/abc

Re: Grit: Rewriting Git in Rust with agents

#158

Post by wongarsu »

Yokohiii wrote: post #64
squidsoup wrote: post #43

I guess software licenses are meaningless now since anyone can decide their llm clone is not derivative.

Currently some act like it is fine to translate a project and change the license. Recently Casey Muratori said in a adjacent context that the microsoft AI push may be related to the fact that they have a long standing and elaborate codebase. A large historic software company could have advantages to train models. They could provide extra value with their IP. Now their IP is potentially in their models and accessible…

A lot of their IP has been leaked over the years anyways. Source code of Windows XP is easily available, and there was the 2022 leak that contained the sources of Bing, Bing Maps, Cortana, etc

Re: Grit: Rewriting Git in Rust with agents

#159

Post by wongarsu »

Ferret7446 wrote: post #93
MBCook wrote: post #53

Earlier quoted context omitted.

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

But there is already gitoxide, an established git reimplementation in git. It even provides a library

gitoxide was started in 2018, back when we were all writing code by hand, and has some reasonable adoption in the rust ecosystem. It's not feature complete, but if that was the issue then surely fixing that would be better than starting from scratch

Re: Grit: Rewriting Git in Rust with agents

#160

Post by beacon294 »

jmyeet wrote: post #144
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.

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.

Post reply on HN