> 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.<p>Hmm. That's going to be interesting.
Obligatory: <a href="https://github.com/chardet/chardet/issues/327" rel="nofollow">https://github.com/chardet/chardet/issues/327</a>
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.<p>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 on the legal decisions on what the copyrightable creative elements in code actually are.<p>If I was the author though... there would be no way that I would be volunteering to be a test case like this. Also seems just rude for no reason.
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.
functional parts not being copyrightable means that you can't claim a program is a copyright violation based on the fact it does the exact same thing based on compatibility reasons (you can copy what the program does). E.g. git stores refs in .git/refs, so does grit, that's not a violation. You still can't copy the program.
Yes... and now we get to the fact specific question of "did they copy the program". Or actually the answer to that is plainly "no" - they made something similar from it - and didn't run ctrl-c ctrl-v in an unlicensed manner, but "did they copy the relevant facets of the program into the new similar thing".
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.<p>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.
Well compilers are a mechanical transformation and if that were sufficient to free you of IP law then IP law wouldn't work.<p>An LLM is also a computer program which takes input and produces output related in some way to that input. However I don't think most people would view it as a "mere" mechanical transformation. One could tautologically argue that an LLM blends the user input with the training inputs which is a sort of transformation and further that the LLM itself is a computer program thus it is mechanical in nature. However it should be immediately obvious that such an overly literal interpretation is in danger of subsuming human work as well. Where the boundary lies is an unanswered question.<p>Related, compilers can pose a problem depending on what the output includes. For example common lisp compilers that aren't under a permissive license are a minefield because regardless of what anyone might say the image that gets output includes (approximately) the full language implementation verbatim in addition to the user's program.
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).
<a href="https://www.copyright.gov/newsnet/2025/1060.html" rel="nofollow">https://www.copyright.gov/newsnet/2025/1060.html</a><p>> 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.<p>Well that's interesting.
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.
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.<p>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
> Not a fan of this trend of "cleaning" GPL licensed software
> Wether it's technically legal or not, it's disgusting behavior IMO.<p>GNU was originally developed to "clean" UNIX from the AT&T license.
I'm not a copyright lawyer, but it seems pretty clear to me you can't wash a license using an LLM.<p>[US jurisdiction]:
Anything in the result written by the LLM can not be copyright by anyone.<p>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.<p>As a work of an LLM, the entirety presumably can not be copyright, at all. Portions written by humans presumably carry their original copyright.
> [US jurisdiction]: Anything in the result written by the LLM can not be copyright by anyone.<p>This is a bit stronger than the actual report where this has been discussed finds. See part 2 in <a href="https://www.copyright.gov/ai/" rel="nofollow">https://www.copyright.gov/ai/</a> for details, but TL;DR, parts where humans have control over the expression may be copyrightable. But working out which parts those are is likely a difficult question (would likely require proof of provenance across many of those LLM sessions)
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.<p>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.<p>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.<p>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 <i>guess</i> probably. But I'm not 100% sure anymore. I wouldn't risk it however.<p>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.<p>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).<p>Anyway, it's a crazy position to take.
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?
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 file, a packfile, or a reftable. etc.<p>There is no way anyone would ever use this for it's CLI - it will almost certainly always be slower and worse in every way, even if I get it stable (which it's currently not). You can use libgit2 (a project I also helped kickstart), or Gitoxide (a project GitButler also currently helps drive) - they are faster and better in nearly every way, but they are not feature complete.<p>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.
Nice experiment, but a bit expensive.<p>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 <i>want</i> to do that more.<p>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.<p>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.<p>May look differently from your vantage point though.<p>[1]: <a href="https://github.com/gritzko/beagle" rel="nofollow">https://github.com/gritzko/beagle</a><p>[2]: <a href="https://replicated.wiki/blog/abc" rel="nofollow">https://replicated.wiki/blog/abc</a>
But libgit2 exists, right? It may not have 100% feature parity with git, but that's a linkable library that gives you a lot of functionality when working with git repos.
the author of this post (whom you were responding to) made `libgit`, the library that preceded `libgit2`, and contributed to libgit2 a long time ago as well. Here he is in 2010 writing about libgit2: <a href="https://github.blog/news-insights/libgit2-a-git-linkable-library/" rel="nofollow">https://github.blog/news-insights/libgit2-a-git-linkable-lib...</a>
License washing
How else could they launder the git license and set themselves up for a bait and switch later down the line?
Soon all the crustaceans will realize that C is better because AI can find all the vulnerabilities anyway.<p>Rust is some ugly poo.
> 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 <a href="https://jonready.com/blog/posts/claude-fable5-is-allowed-to-sabotage-your-app-if-youre-a-competitor.html" rel="nofollow">https://jonready.com/blog/posts/claude-fable5-is-allowed-to-...</a> it certainly feels more Genie-like.<p>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 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.<p>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.<p>Now their IP is potentially in their models and accessible to anyone. If they actually train models on their IP, anyone could implement their APIs and slap a GPL license on it.<p>At that point, things will get very interesting.
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
No one is training their models on their closed sourced proprietary code. They own github, why would they need to do this.
They were already quite meaningless since nearly every FOSS copyright owner doesn't sue violators.
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<p>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.<p>Link: <a href="https://unknownworlds.com/en/news/spark-engine-questions-and-answers-1-2" rel="nofollow">https://unknownworlds.com/en/news/spark-engine-questions-and...</a>
> They all seem to be rewrites for the sake of "performance".<p>And yet this performs dramatically worse.<p>A slower, untested, incomplete git implementation, all for the low low price of $10-$15,000.<p>And don’t forget it wasted a bunch of human time in the process.<p>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?<p>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?
It's not for performance, it's for Rust.<p>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.<p>(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<p>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
It's not for Rust, it's for Library.<p>Well, it's sort of for Rust. GitButler is written in Rust and Jujutsu is written in Rust and we're both depending on fork/exec'ing to an unknown Git binary with no linkable library and no control over the subprocess to do a range of networking stuff. Neither Gitoxide or libgit2 are capable of this either, as much as I love and support those projects.<p>This project is entirely about providing a feature complete (even if sloppy) library implementation of Git, which does not otherwise exist.
But... it's memory safe. Not that git has any important memory issue, but now people with skill issues in C can contribute to it without breaking stuff.
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.
> A pretty fun experiment and I think we can shape this into something truly useful to the whole community.<p>Agree with first half of this sentence, we should all have fun with experiments.<p>> 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.<p>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: <a href="https://aperocky.com/blog/post.html?slug=unix-philosophy-agentic" rel="nofollow">https://aperocky.com/blog/post.html?slug=unix-philosophy-age...</a>
You cut that citation conveniently short.<p>> 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.
Added it in full. It still squarely falls under "this is for fun/are you seriously doing this for this purpose" territory for me.<p>git operate on the filesystem level, the unix behavior is just getting buried. You cannot rewrite git into a linkable library and decide it's now not unix. It's entire behavior is unix, which is why it's awesome.
My intent with this project is not to replace Git in any way. I don't care about the CLI part of this project.<p>The point is to provide a feature-complete reentrant linkable library. Even if it's an ugly and slow one, this is still the only one thing that exists that covers those points - Gitoxide and libgit2 are both awesome but they are not feature complete.
Isn’t git already just an interface over libgit? How is that different?
Git is famously not built around a (reusable) library, hence why we have things like libgit2 (unrelated to git) and why any porcelain on top of git has to resort to calling the binary and parsing its text output.
libgit.a isn't reentrant. It will call `die()` on many errors. If you link to it in a long running binary, it will kill your process on error.<p>Libgit2 is meant to address this and I was heavily involved in the development of that project 15 years ago. It's great but it's not feature complete and it's development is also completely separate from git development, so it's out of sync and constantly struggling to keep up.
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.
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.<p>[1]. <a href="https://github.com/ianm199/lua-rs/tree/main" rel="nofollow">https://github.com/ianm199/lua-rs/tree/main</a> Lua<p>[2]. <a href="https://github.com/ianm199/valdr" rel="nofollow">https://github.com/ianm199/valdr</a> Valkey/ Redis<p>[3]. <a href="https://github.com/ianm199/nginx-rs-port" rel="nofollow">https://github.com/ianm199/nginx-rs-port</a> nginx<p>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.
Does anyone plan to use this?<p>Similarly, is there any momentum left for Cloudflare's EmDash? I can barely find any discussion after April.
It'd seem weird to plan to use this until the readme stops saying<p>> it has been nearly entirely written by agents and has not been used for realsies. It's probably currently unusably slow or completely broken in ways that are not exercised in the test suite.<p>Right now it's someone else's experiment that is still in the "might or might not pan out" stage.<p>There are a bunch of projects using the similar (not vibe coded, less fully featured) gitoxide project - there is demand for git-as-a-library.
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.
Wordpress is/was successful because it's braindead and has a solid userbase. I am not to flame WP, but it's a quality to target a specific group of consumers.<p>It's an organic success, hard to replicate. If at all, CF can only make people migrate with massive effort. Marketing effort, selling lots of snake oil in the process. WP wont just hop on the hot new thing, WP is the definition of the opposite. It works for them. Why change.<p>Git is the same on the other side. It requires maintenance and improvements, surgical and correct. No git maintainer has time to learn a gigantic new codebase and they will stick with what works for them. For git users there are no advantages. So similarly it would require a long time effort to push the project, building trust that it is somehow better, probably requiring Linus to say "it's great".
> 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.<p>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.<p>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.<p>If anyone digs into the binary size, please share what you find.
I would also be interested.<p>I haven't dug into this at all yet, nor have I tried to optimize the size (or really, anything else).<p>However, the library part will be less than half of this - a lot of code is spent on the CLI specific stuff and would not be part of the library, which is mostly what I care about for the purposes of this project. The CLI part is just to try to prove the point that it actually does what Git does. The library part is what might be useful in that nothing else exists that does all of the things that it does (provide a reentrant linkable library that is feature complete with Git).
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
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?
In 6 months, seeing no adoption, move the repo to maintenance mode. Archive in 12 months.
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).<p>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.
He will be probably super happy for starring the project.
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.
Grit was the name of a _Ruby_ implementation of git way back when: <a href="https://github.com/mojombo/grit/" rel="nofollow">https://github.com/mojombo/grit/</a>. 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!
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.<p>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. :)
Okay name is taken. Let's rename it to Grift.
I did something similar and called it gitredoxide since I started with gitoxide.
pretty dystopian to ask a robot to recreate your favorite software just so you can relicense it for your business venture
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.<p>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.
> Our goal is a linkable library, which makes GPL impossible<p>Not impossible. It forces the code using the library to be under a GPL-compatible license and requires the binary to be released under the GPL license.<p>The distinction is quite important. It's only impossible in the mind of someone who wants to release proprietary software. Even for people releasing software under permissive license it's not impossible, just highly inconvenient (and the LGPL is always an option in this case).
>We're choosing a license that is usable by the entire community.<p>What a weaselly way to put it.<p>A GPL library, as I'm sure you know, is perfectly usable by anyone including jujutsu and anyone else. They just have to also license under the GPL and this is no barrier to open source projects.
Theres already git-in-rust project that is making good progress<p><a href="https://github.com/gitoxidelabs/gitoxide" rel="nofollow">https://github.com/gitoxidelabs/gitoxide</a>
Gitoxide is also developed primarily by Byron, who also is part of the GitButler team. We're pushing both projects forward.
Gitoxide is mentioned in this write up, yes,<p>> <i>Currently both Gitoxide and libgit2's networking functionality is either partial, slow or non-existant. Both GitButler and Jujutsu rely on forking out to Git in order to push or pull data. A big reason for this is the incredibly complicated credential logic involved, but all of this is (theoretically) currently covered in Grit.</i>
I continue to be surprised by the lack of understanding around copyright law when it comes to AI.
So, they "decided" it's not a derivative and thus can be listened under MIT instead of GPL....
Yeah, that's usually how contracts work.<p>You <i>decide</i> whether you have followed it or not. The other party will <i>decide</i> if they agree. If in dispute, you go to a judge and they <i>decide</i> also.
a lot of things are just "decided" really.<p>it's just in this case it's the author.
we'll have to wait and see who decides to challenge it
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?<p>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.<p>Don't bother.<p>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.<p>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 hate all you llm people, you're ruining everything, shoving slop down everyone's mouth and telling us you now have superpowers. No you're stealing and making everything as shitty as possible in the process.<p>I pray everything switches to usage based billing and the curtains can close on this era.
[dead]
> 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.<p>Why not 100%?<p>> 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<p>> 41,715 / 42,001 tests passing (99.3%)<p>So it is not entire then but somehow that was worth burning $8,000~ dollars worth of tokens?
> Why not 100%?<p>From the article<p>> 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 - email related stuff, i18n, perforce/svn importers, some of the midx/bitmap stuff - things of that nature. However, for everything that I'm sure is relevant to nearly anyone reading this, the Grit library/CLI can now fully pass the Git test suite.
So .7% tests fail therefor it was 100% a waste of time?
I think we are talking about ROI in terms of solving real world problems and making real impact, not the fact that a tool has been ported from language X to language Y.
Given the author already admitted that the implementation was slow anyway, you are no better off of using gitoxide instead and that has support for Windows where-as Grit does not.
> Currently both Gitoxide and libgit2's networking functionality is either partial, slow or non-existant. Both GitButler and Jujutsu rely on forking out to Git in order to push or pull data. A big reason for this is the incredibly complicated credential logic involved, but all of this is (theoretically) currently covered in Grit.
Regardless, what's the point?
> One of the main things I would like to be able to use it for is to be able to bundle complex push/fetch functionality into GitButler and other standalone Git tools needing network functionality (such as Jujutsu).<p>> Having parts of Git as discrete, embeddable slices of library also enables things like building custom Git servers or client functionality in Rust.<p>> 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. Perhaps you could simply use the subset you need.
The article starts out with paragraphs about the history and motivation.<p>> it made me wonder about the feasibility of using that same approach to accomplish something I've been dreaming about for 15 years now,<p>> which means that it's difficult to use it in long running processes without fork/exec overhead for everything.<p>> What if we used the same basic idea that Anthropic used on their from-scratch C compiler? Start a brand new implementation, design it as a Rust library, then throw a swarm of agents at the problem
maybe it's an academic project. proof they could reimplement something useful & complex?
There is often good reasons for these purposeful digressions. I.e. in nginx the unit tests cover cyphers that are considered unsafe and not supported by modern libraries like rustls <a href="https://github.com/rustls/rustls" rel="nofollow">https://github.com/rustls/rustls</a>. It is reasonable to make a new implementation and leave behind a bit of baggage.
The author actually estimated $10-$15,000 worth of tokens.
It depends whether the 0.7% failures are testing deliberately unimplemented features like email or is in corner cases in implemented features. It sounds like it's at least mostly the former, hopefully it's 100% the former.<p>I don't care if any git I use has email features. IIUC, even most of the people that use git with email don't directly use the email features, they use the patch set features like `git am`. I expect `git am` to work, I don't expect git to actually do email.
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.<p>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.<p>Because of this moats around business due to difficulty of implementation are effectively gone.