> the result is Grit, a from-scratch, library-based, memory-safe, idiomatic Rust reimplentation of Git that passes over 99% of the entire Git test suite.
Why not 100%?
> It's not actually passing every single test, though that is on purpose. I did mark some parts of the testing suite as "skipped" because I don't think it's worth recreating them in a library like this
> 41,715 / 42,001 tests passing (99.3%)
So it is not entire then but somehow that was worth burning $8,000~ dollars worth of tokens?
they still haven't explained why I should bother. Is it faster, easier, more efficient, more capable, more scalable on large codebases, supports better workflows?
In fact, I would rather it stay C for 15 more years.
I'm assuming you didn't read the article, since I'm pretty sure I covered all of this, but I'm happy to respond.
Don't bother.
It's probably not for you. It's slower, more obtuse, more bloated, less capable, exponentially less scalable at any size. Canonical Git is better in every way, except being a linkable library.
Even in the arena of being linkable libraries that can do Git stuff, both Gitoxide (Rust) and libgit2 (C which has git2 crate Rust bindings) are both better, they're just not feature complete. That is the only point of this project.
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", because the cost is now lower bc of AI.
If that was true they'd use the original license. They are not. The whole RiiR movement is very obviously switching away from a pro-user license (GPL).
> 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.
I'm not a copyright lawyer, but it seems pretty clear to me you can't wash a license using an LLM.
[US jurisdiction]:
Anything in the result written by the LLM can not be copyright by anyone.
Anything in the result written by a human can be, and if it was all emitted by the LLM then that portion originally written by a human carries its own copyright.
As a work of an LLM, the entirety presumably can not be copyright, at all. Portions written by humans presumably carry their original copyright.
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.
It is also rather ungrateful. The only reason we have Linux desktops today, and the only reason companies like Red Hat and Canonical has a billion dollar business model is the GPL.
The BSDs had a head start, and were superior in almost every way for the better part of a decade at least, but have remained niche compared to Linux. It's not even close. Now, there may be many other reasons to this, including the personalities and culture of the Linux developers, but you simply can't ignore the impact of the license which have kept all the commercial Linux products inside the fold.
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's escaped our license"? Of course not. It's just silly.
ingesting the source code and producing output in another language is quite clearly a derivative work. You don't need to be an IP lawyer to figure that out.
Now, if you went to Calude and gave it documentation and told it to produce something that was compatible, would that be a derivative work and thus covered by the GPL? I would guess probably. But I'm not 100% sure anymore. I wouldn't risk it however.
Here's another thought experiment: what if someone takes this supposedly MIT licensed source tree, plugs it into another LLM and asks it to produce the output in C? Now how is it licensed? It might be very similar. After all, there are only so many ways to produce a SHA1 hash and so many ways to do a command line parser.
But this then makes it an interesting legal issue. In the Oracle v. Google court case, this was a key issue. Google successfully argued there's only so many ways to write a loop so just because a loop is similar to the source, that doesn't mean it's copyright infringement (as Oracle argued).
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.
Mathematically, does similarity/intelligibility of one equation to another have any bearing on whether the one was derived from the other? Philosophically? Legally? I'm not a copyright lawyer, but that's the crux of the matter to me: did you start with something, and iterate from it (even if it was so many times as to be transformed beyond recognition), or is it something more akin to clean-room reverse engineering?
This is not a proper black-box reimplementation, I doubt they can get away with that. And that's not mentioning all other obvious ethical concerns of course.
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 copyright standpoint, however, only the first argument there is relevant. Grit is an independently authored implementation of Git-compatible behavior, with negligible similarity to Git source code.
I think antirez summarized the situation quite well and I broadly agree with his position: https://antirez.com/news/162
I think that those in the community who know me and have worked with me in the Git and open source communities for the last 20 years know that my intentions are to contribute, share and foster innovation and learning. Many of the main authors of the Git source code are friends of mine and I have no intention to steal anything from anyone, only to make their great ideas more broadly useful.
Are you a trained lawyer? Okay but presumably not practicing in the last twenty years.
You know that all contributions to the Git project has to be signed off as either being made by yourself or being handed over by someone who has signed off on that certficate of origin. For everyone on every change. Even the lead developers so to speak. And you spend some thousands of dollars and run an AI analyis tool to wash your hands?
Who are you to do that? Oh wait I forgot, you are Mr. Chacon. A hand in everything Git and friendly with everyone in Git who matters for twenty years. Remind us next time as well so I don’t forget.
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 and Jujutsu (and pretty much every other Git-based tool in the world). I'm pretty sure I can get the project good enough at these networking ops (including all the hairy credential stuff) to be able to not need those fork/exec calls.
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. The reason was because I wanted to learn the ins and outs before taking on the most complex portion.
Happy to answer any questions on the approach! When I started a few weeks ago the harnesses on their own were not good enough to get very far without a "meta harness" of sorts but that is changing largely with Claude Workloads and Mythos. A lot of the work is developing some custom tooling to move these along faster.
This is coming from a cofounder at github, someone who probably knows precisely what the GPL is for. Whatever the legal merits, building on a GPL3 project's complete test suite and relicensing under MIT is not acting in good faith toward the original authors. I really find it disgusting and it makes me want to avoid gitbutler entirely.
> A pretty fun experiment and I think we can shape this into something truly useful to the whole community.
Agree with first half of this sentence, we should all have fun with experiments.
> It was never based on a linkable and reentrant library, but instead on a "Unix" philosophy of chaining together simpler commands, which means that it's difficult to use it in long running processes without fork/exec overhead for everything.
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.
We're choosing a license that is usable by the entire community. Our goal is a linkable library, which makes GPL impossible. If we had chosen to go with LGPL or GPL with linking exception (like libgit2), it would have the same issue of changing the license, so we went with whatever was the most permissive so everyone could use it for anything if they wish. This has nothing to do with business - I hope I can get the project to the point where Jujutsu or whomever can use whatever is valuable here for whatever they want.
We clearly learned from how Git does operations and emulated it in order to function interoperably, the same way that Gitoxide and libgit2 have, and released it under a license that would be the most valuable for people wanting to use a linkable library, the same way that Gitoxide and libgit2 have.
Grit was the name of a _Ruby_ implementation of git way back when: https://github.com/mojombo/grit/. I believe it's actually what GitHub was built on then.
I started the project as Gust, but felt like Grit was such a better name. I asked Tom if I could boot the name back up again because I always liked it and he said it was fine.
Also, I worked on the Ruby Grit pretty extensively during the early days of GitHub, so hopefully I earned the right to carry on the mantle. :)
> 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 split up into multiple programs. I'm not comparing apples to apples, but this is weird.
If anyone digs into the binary size, please share what you find.
> It's like giving wishes as a genie. You gotta be super explicit with the ground rules.
I have used the genie analogy before. It used to feel more like a Golem but now with the whole Fable sabotage mode https://jonready.com/blog/posts/claude-fable5-is-allowed-to-... it certainly feels more Genie-like.
Previously I described it as "Models give you what you ask, for not what you want". Now with Fable they don't even give you want you want so idk.
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 which case you might need to move away from git, and a rust rewrite will not help in any way whatsoever. So again … why?
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.
if we conquer the universe, i would love to leave one planet alone for rust users. in this planet, the only allowed programming langauge is RUST! everything should be written in RUST
65 comments
[ 3.3 ms ] story [ 84.6 ms ] threadWhy not 100%?
> It's not actually passing every single test, though that is on purpose. I did mark some parts of the testing suite as "skipped" because I don't think it's worth recreating them in a library like this
> 41,715 / 42,001 tests passing (99.3%)
So it is not entire then but somehow that was worth burning $8,000~ dollars worth of tokens?
In fact, I would rather it stay C for 15 more years.
Don't bother.
It's probably not for you. It's slower, more obtuse, more bloated, less capable, exponentially less scalable at any size. Canonical Git is better in every way, except being a linkable library.
Even in the arena of being linkable libraries that can do Git stuff, both Gitoxide (Rust) and libgit2 (C which has git2 crate Rust bindings) are both better, they're just not feature complete. That is the only point of this project.
If that was true they'd use the original license. They are not. The whole RiiR movement is very obviously switching away from a pro-user license (GPL).
Similarly, is there any momentum left for Cloudflare's EmDash? I can barely find any discussion after April.
Hmm. That's going to be interesting.
[US jurisdiction]: Anything in the result written by the LLM can not be copyright by anyone.
Anything in the result written by a human can be, and if it was all emitted by the LLM then that portion originally written by a human carries its own copyright.
As a work of an LLM, the entirety presumably can not be copyright, at all. Portions written by humans presumably carry their original copyright.
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.
The BSDs had a head start, and were superior in almost every way for the better part of a decade at least, but have remained niche compared to Linux. It's not even close. Now, there may be many other reasons to this, including the personalities and culture of the Linux developers, but you simply can't ignore the impact of the license which have kept all the commercial Linux products inside the fold.
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's escaped our license"? Of course not. It's just silly.
ingesting the source code and producing output in another language is quite clearly a derivative work. You don't need to be an IP lawyer to figure that out.
Now, if you went to Calude and gave it documentation and told it to produce something that was compatible, would that be a derivative work and thus covered by the GPL? I would guess probably. But I'm not 100% sure anymore. I wouldn't risk it however.
Here's another thought experiment: what if someone takes this supposedly MIT licensed source tree, plugs it into another LLM and asks it to produce the output in C? Now how is it licensed? It might be very similar. After all, there are only so many ways to produce a SHA1 hash and so many ways to do a command line parser.
But this then makes it an interesting legal issue. In the Oracle v. Google court case, this was a key issue. Google successfully argued there's only so many ways to write a loop so just because a loop is similar to the source, that doesn't mean it's copyright infringement (as Oracle argued).
Anyway, it's a crazy position to take.
F-ing scumbags. It's already free, but they still decide to steal it.
Take this (assuming it's not slop), relicence as GPL, submit upstream (imagine it's accepted for a moment...).
If they proceed with license washing then from the Rust version, it's certainly derived work.
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 copyright standpoint, however, only the first argument there is relevant. Grit is an independently authored implementation of Git-compatible behavior, with negligible similarity to Git source code.
I think antirez summarized the situation quite well and I broadly agree with his position: https://antirez.com/news/162
I think that those in the community who know me and have worked with me in the Git and open source communities for the last 20 years know that my intentions are to contribute, share and foster innovation and learning. Many of the main authors of the Git source code are friends of mine and I have no intention to steal anything from anyone, only to make their great ideas more broadly useful.
You know that all contributions to the Git project has to be signed off as either being made by yourself or being handed over by someone who has signed off on that certficate of origin. For everyone on every change. Even the lead developers so to speak. And you spend some thousands of dollars and run an AI analyis tool to wash your hands?
Who are you to do that? Oh wait I forgot, you are Mr. Chacon. A hand in everything Git and friendly with everyone in Git who matters for twenty years. Remind us next time as well so I don’t forget.
Malus – Clean Room as a Service https://news.ycombinator.com/item?id=47350424
Just like for 1984 and the Torment Nexus, someone took the concept not as warning but as instruction manual.
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 and Jujutsu (and pretty much every other Git-based tool in the world). I'm pretty sure I can get the project good enough at these networking ops (including all the hairy credential stuff) to be able to not need those fork/exec calls.
[1]. https://github.com/ianm199/lua-rs/tree/main Lua
[2]. https://github.com/ianm199/valdr Valkey/ Redis
[3]. https://github.com/ianm199/nginx-rs-port nginx
Happy to answer any questions on the approach! When I started a few weeks ago the harnesses on their own were not good enough to get very far without a "meta harness" of sorts but that is changing largely with Claude Workloads and Mythos. A lot of the work is developing some custom tooling to move these along faster.
Agree with first half of this sentence, we should all have fun with experiments.
> It was never based on a linkable and reentrant library, but instead on a "Unix" philosophy of chaining together simpler commands, which means that it's difficult to use it in long running processes without fork/exec overhead for everything.
Ahhh now we have philosophical disagreement in the only place in the entire article that says "why". Unix is a feature, it's arguably more important in current time: https://aperocky.com/blog/post.html?slug=unix-philosophy-age...
https://github.com/gitoxidelabs/gitoxide
https://github.com/gitbutlerapp/gitbutler
We clearly learned from how Git does operations and emulated it in order to function interoperably, the same way that Gitoxide and libgit2 have, and released it under a license that would be the most valuable for people wanting to use a linkable library, the same way that Gitoxide and libgit2 have.
So you didn't just let an AI go nuts with access to the source code of Git so as to produce a derivative work?
Also, I worked on the Ruby Grit pretty extensively during the early days of GitHub, so hopefully I earned the right to carry on the mantle. :)
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 split up into multiple programs. I'm not comparing apples to apples, but this is weird.
If anyone digs into the binary size, please share what you find.
Previously I described it as "Models give you what you ask, for not what you want". Now with Fable they don't even give you want you want so idk.
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.
Especially if there's the same thing that already exists in open source that the model can plagiarize for you.