Live data from Hacker News

Grit: Rewriting Git in Rust with agents

blog.gitbutler.com

51–60 of 318 posts

Re: Grit: Rewriting Git in Rust with agents

#51
post #46

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 created and named the Grit library that used to power GitHub. Scott Chacon (fellow GitHub cofounder, now CEO of GitButler) specifically asked my permission to re-use Grit as the name of this project, which I gladly granted. R is for Ruby. R is for Rust! Grit is dead. Long live Grit!

Re: Grit: Rewriting Git in Rust with agents

#52

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?

The agents did all the work but _somebody_ has to test it for real on their own data to find the edge cases overlooked by AI. That's what users are for nowadays.

Re: Grit: Rewriting Git in Rust with agents

#53
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 time in software development resources?

Ok. AI can seemingly port stuff if you don’t test it thoroughly. I think that’s already been proven. At this point I’m seeing less and less value from these kind of things. I’m sure it was fun for the author, but how does it help other people?

Re: Grit: Rewriting Git in Rust with agents

#54
post #33

Earlier quoted context omitted.

they would be just wrong. I hope someone with standing sues

I don't think it's that clear cut. The functional parts probably aren't copyrightable, only the stylistic ones. It's going to be a mix of courts applying laws in new ways that hasn't been done before and fact specific questions about what actually persisted through the LLM if it goes to court. I'd be fascinated to see what happens if it does. Both in the analyses that we'd get of what the LLM did to the codebase and…

It probably would have been less bad if he had chosen MPL-2.0 or LGPL-2.1-or-later. But he chose MIT, which cuts at the core of the intent of licensing the project with a share-alike license.

Re: Grit: Rewriting Git in Rust with agents

#55
post #9

Does anyone plan to use this? Similarly, is there any momentum left for Cloudflare's EmDash? I can barely find any discussion after April.

I was immediately excited about this wrapped in Python because the current Python git bindings are kind of obtuse, but they do work so I guess I can't complain.

Re: Grit: Rewriting Git in Rust with agents

#56

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

Isn’t git already just an interface over libgit? How is that different?

Re: Grit: Rewriting Git in Rust with agents

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

they would be just wrong. I hope someone with standing sues

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

Re: Grit: Rewriting Git in Rust with agents

#58
post #9

Does anyone plan to use this? Similarly, is there any momentum left for Cloudflare's EmDash? I can barely find any discussion after April.

I was immediately excited about this wrapped in Python because the current Python git bindings are kind of obtuse, but they do work so I guess I can't complain.

But why switch to this?

Why not just make better Python bindings to libgit?

Re: Grit: Rewriting Git in Rust with agents

#59
post #33

Earlier quoted context omitted.

I don't think it's that clear cut. The functional parts probably aren't copyrightable, only the stylistic ones. It's going to be a mix of courts applying laws in new ways that hasn't been done before and fact specific questions about what actually persisted through the LLM if it goes to court. I'd be fascinated to see what happens if it does. Both in the analyses that we'd get of what the LLM did to the codebase and…

It probably would have been less bad if he had chosen MPL-2.0 or LGPL-2.1-or-later. But he chose MIT, which cuts at the core of the intent of licensing the project with a share-alike license.

Tell me, can I create a copyrighted video that's not GPL licensed using ffmpeg? Now tell me how creating a rust library using the git test suite is different?

Re: Grit: Rewriting Git in Rust with agents

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

> Quake III in Python Probably doable - I remember most of Natural Selection 2 was Lua and it's more than a decade old at this point.

For Natural Selection 2, it was mainly the gameplay logic that was Lua, all running on their bespoke C++ game engine called Spark. But yeah, modern Python and Lua can be pushed to high performance.

Link: https://unknownworlds.com/en/news/spark-engine-questions-and...

Post reply on HN