13 ms·

Grit: Rewriting Git in Rust with agents

178 points by cbrewster 3mo ago

aeon_ai 3mo ago
I continue to be surprised by the lack of understanding around copyright law when it comes to AI.
rvz 3mo ago
> 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?
- insanitybit 3mo ago
  So .7% tests fail therefor it was 100% a waste of time?
  - Zopieux 3mo ago
    Regardless, what's the point?
    - tonymet 3mo ago
      maybe it's an academic project. proof they could reimplement something useful & complex?
    - sharkjacobs 3mo ago
      > 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). > Having parts of Git as discrete, embeddable slices of library also enables things like building custom Git servers or client functionality in Rust. > 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.
    - insanitybit 3mo ago
      The article starts out with paragraphs about the history and motivation. > it made me wonder about the feasibility of using that same approach to accomplish something I've been dreaming about for 15 years now, > which means that it's difficult to use it in long running processes without fork/exec overhead for everything. > 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
  - rvz 3mo ago
    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.
    - sharkjacobs 3mo ago
      > 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.
  - fg137 3mo ago
    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.
- bryanlarsen 3mo ago
  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. 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.
- ianm218 3mo ago
  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 https://github.com/rustls/rustls https://github.com/rustls/rustls. It is reasonable to make a new implementation and leave behind a bit of baggage.
- gpm 3mo ago
  > Why not 100%? From the article > 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.
- MBCook 3mo ago
  The author actually estimated $10-$15,000 worth of tokens.
tonymet 3mo ago
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.
- schacon 3mo ago
  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.
  - tonymet 3mo ago
    grep didn’t indicate anything interesting. S/n was very low. Thanks.
heyts 3mo ago
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
- jamesfinlayson 3mo ago
  > 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.
  - jordand 3mo ago
    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-answers-1-2 https://unknownworlds.com/en/news/spark-engine-questions-and...
    - jamesfinlayson 3mo ago
      Ah my mistake - I know they ditched Source to pursue their own engine and thought they were going all in on Lua, but doing the whole engine in Lua would have been a struggle I think.
- MBCook 3mo ago
  > 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?
fg137 3mo ago
Does anyone plan to use this? Similarly, is there any momentum left for Cloudflare's EmDash? I can barely find any discussion after April.
- gpm 3mo ago
  It'd seem weird to plan to use this until the readme stops saying > 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. Right now it's someone else's experiment that is still in the "might or might not pan out" stage. 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.
  - schacon 3mo ago
    I would not use this except to help us test it if interested. I'm announcing it because it's interesting and a milestone in the breadth of test coverage it can pass. It almost certainly cheated on a bunch of those tests and is not feature complete yet. The author of gitoxide is also working on GitButler (who worked on this project) and we're pushing both projects forward and actively using and developing Gitoxide as well. This is simply a different and hopefully complimentary approach to the same problem.
    - fg137 3mo ago
      > because it's interesting and a milestone in the breadth of test coverage it can pass. Sorry, no. Let me be candid and point out that this has achieved exactly nothing except lighting $8k on fire. Put it this way: if I suggest to my boss, "I want to spend $8k of company money to port git to Rust to just see how many tests can pass in that project, even though I don't plan to develop new features with the project, and I don't care about adoption", he is going to shot down the idea in half a second and seriously question my competence.
- Yokohiii 3mo ago
  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. 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. 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".
Philpax 3mo ago
> 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.
- nextaccountic 3mo ago
  they would be just wrong. I hope someone with standing sues
  - gpm 3mo ago
    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 on the legal decisions on what the copyrightable creative elements in code actually are. 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.
    - Conan_Kudo 3mo ago
      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.
      - joshka 3mo ago
        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?
gdgghhhhh 3mo ago
So, they "decided" it's not a derivative and thus can be listened under MIT instead of GPL....
- subygan 3mo ago
  a lot of things are just "decided" really. it's just in this case it's the author. we'll have to wait and see who decides to challenge it
- madeofpalk 3mo ago
  Yeah, that's usually how contracts work. You decide whether you have followed it or not. The other party will decide if they agree. If in dispute, you go to a judge and they decide also.
  - cmrdporcupine 3mo ago
    Where's the crowdfunded lawsuit I can donate to?
huflungdung 3mo ago
[dead]
imoverclocked 3mo ago
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?
- fg137 3mo ago
  In 6 months, seeing no adoption, move the repo to maintenance mode. Archive in 12 months.
- Yokohiii 3mo ago
  He will be probably super happy for starring the project.
- 0x000xca0xfe 3mo ago
  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.
- schacon 3mo ago
  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.
  - witx 3mo ago
    I won't touch relicensed code even if you payed me. This is morally, if not legally, wrong.
ianm218 3mo ago
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. [1]. https://github.com/ianm199/lua-rs/tree/main https://github.com/ianm199/lua-rs/tree/main Lua [2]. https://github.com/ianm199/valdr https://github.com/ianm199/valdr Valkey/ Redis [3]. https://github.com/ianm199/nginx-rs-port 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.
- jabwd 3mo ago
  Yeah I got one, why? You aren't learning anything, you are just copying code from other codebases and smashing it together to make some nginx-rust thingie... for what actual goal?
  - ianm218 3mo ago
    Well the biggest goal was to be useful. Nginx serves ~20% of the web, memory unsafe languages might just become untractable for critical exposed to the web infra if the rate of critical CVE's on these rises faster than they can be patched, so a drop in replacement would be a big deal in that world. But in terms of learning I'm learning relatively little about how to type Rust into an editor but a lot about how to set up agentic loops that can autonomously get tests to pass and improve performance. For example if you just tell a frontier model (gpt5.5 or Claude Code 4.8) to make some portion of the tests pass they will take forever and just bang their heads against it. I developed a framework to mimic a lot of these tests in nginx... but in minimum non blocking ways so you can run many in parallel with short feedback loops. Similar for performance - how to make tons of performance benchmark and expose maximum telemetry for agents to go and analyze the hotpaths etc.
dabedee 3mo ago
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.
- joshka 3mo ago
  I think you're saying that you don't believe in the freedoms to use the GPL licensed test suite for certain purposes which are explicitly allowed by the GPL. You don't get to choose a license and then add extra terms to it when you don't feel like it's up to scratch. That's something explicitly not allowed by the GPL license.
  - MBCook 3mo ago
    Where does the GPL say you have the freedom to relicense code or derivatives under MIT by fiat? Isn’t having to stay under the GPL a very big part of the GPL license?
    - joshka 3mo ago
      > Where does the GPL say you have the freedom to relicense code or derivatives under MIT by fiat? The first part of this sentence (where in the GPL) is unreached if the second part of it is unmet (relicense code or derivatives) which I contend it likely is. You're begging the question. However: > The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work earlier: > A “covered work” means either the unmodified Program or a work based on the Program. It's that element that would be difficult to prove "work based on the Program"
      - trumpdong 3mo ago
        Asking an LLM "here's a thing, rewrite it in Rust" is pretty clearly creating either a derivative work or a different form of the same work, just like asking a transpiler would.
Aperocky 3mo ago
> 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. 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-agentic https://aperocky.com/blog/post.html?slug=unix-philosophy-age...
- Levitating 3mo ago
  You cut that citation conveniently short. > 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.
  - Aperocky 3mo ago
    Added it in full. It still squarely falls under "this is for fun/are you seriously doing this for this purpose" territory for me. 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.
    - schacon 3mo ago
      My intent with this project is not to replace Git in any way. I don't care about the CLI part of this project. 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.
      - 3mo ago
boredatoms 3mo ago
Theres already git-in-rust project that is making good progress https://github.com/gitoxidelabs/gitoxide https://github.com/gitoxidelabs/gitoxide
- jauntywundrkind 3mo ago
  Gitoxide is mentioned in this write up, yes, > 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.
- schacon 3mo ago
  Gitoxide is also developed primarily by Byron, who also is part of the GitButler team. We're pushing both projects forward.
dabedee 3mo ago
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.
- schacon 3mo ago
  GitButler's source code is available, so we're not asking you to trust us much at all. https://github.com/gitbutlerapp/gitbutler https://github.com/gitbutlerapp/gitbutler
  - deleted 3mo ago
    [deleted]
  - deleted 3mo ago
    [deleted]
  - ersatz-matty 3mo ago
    That's great because we don't.
ewy1 3mo ago
pretty dystopian to ask a robot to recreate your favorite software just so you can relicense it for your business venture
- schacon 3mo ago
  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.
  - 201984 3mo ago
    >We're choosing a license that is usable by the entire community. What a weaselly way to put it. 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.
    - cmrdporcupine 3mo ago
      I love how he uses the word "community", effectively washing away what is really happening which is taking a community protected asset and turning it into a corporate one. Ok, my coffee just kicked in and I'm incensed. Might go do an FSF donation.
  - jraph 3mo ago
    > Our goal is a linkable library, which makes GPL impossible 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. 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).
squidsoup 3mo ago
I guess software licenses are meaningless now since anyone can decide their llm clone is not derivative.
- Yokohiii 3mo ago
  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 to anyone. If they actually train models on their IP, anyone could implement their APIs and slap a GPL license on it. At that point, things will get very interesting.
  - dakolli 3mo ago
    No one is training their models on their closed sourced proprietary code. They own github, why would they need to do this.
    - Yokohiii 3mo ago
      More is better.
  - wongarsu 3mo ago
    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
    - Yokohiii 3mo ago
      Yes but it's illegal to replicate it. A different story if LLMs lift license restrictions.
- trumpdong 3mo ago
  They were already quite meaningless since nearly every FOSS copyright owner doesn't sue violators.
anonova 3mo ago
Grit was the name of a _Ruby_ implementation of git way back when: https://github.com/mojombo/grit/ https://github.com/mojombo/grit/. I believe it's actually what GitHub was built on then.
- Yokohiii 3mo ago
  Okay name is taken. Let's rename it to Grift.
- mojombo 3mo ago
  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!
- schacon 3mo ago
  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. :)
stefanha 3mo ago
> 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.
- schacon 3mo ago
  I would also be interested. I haven't dug into this at all yet, nor have I tried to optimize the size (or really, anything else). 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).
  - andwur 3mo ago
    Looking at just the `grit` executable, 58 of the top 200 largest file->resulting code sources are from clap-rs' derive functionality i.e. it's the command-line parsing. The #1 largest is, surprisingly, merge_trees[1] which comes in at 183kiB final binary size. There isn't so much code in that file that it seems reasonable, so it's potentially one of the derives in use (Debug being a common culprit for bloat) that's blowing it out. After those outliers it starts to level out quickly. Splitting it by crate: `grit` is 13.6MiB, `grit_lib` is 4.8MiB and then it's `std`, `rustls` and `regex_automata` that are the next largest. So as pure library you could hopefully shave off quite a bit of that 25MiB. [1] https://github.com/gitbutlerapp/grit/blob/main/grit-lib/src/merge_trees.rs https://github.com/gitbutlerapp/grit/blob/main/grit-lib/src/...
    - schacon 3mo ago
hankbond 3mo ago
> 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-sabotage-your-app-if-youre-a-competitor.html 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.
usernametaken29 3mo ago
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?
- absintini 3mo ago
  [flagged]
  - galangalalgol 3mo ago
    When we go a full year without a lpe in the linux kernel I'll start considering it...
    - NekkoDroid 3mo ago
      How many of the LPE would rust even fix? They mostly seem logical errors and not memory or threading related race conditions to me.
      - galangalalgol 3mo ago
        This year, none of them. Historically most or all. So that is another caveat. If all future lpe are logic errors I'd start reconsidering the value proposition. I do actually like writing rust though. I don't feel like it slows me down. I also love the simplicity of c vim and gdb, though my first exposure was lattice on the amiga 1000. I wonder if strict typing makes it take fewer tokens to find bugs?
    - absintini 3mo ago
      I mean we’re almost there with Mythos/Fable so there ya go. In two years bye bye rust.
djha-skin 3mo ago
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.
- jraph 3mo ago
  > 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.
- keybored 3mo ago
  This looks more like a blog-blurb (if blogs had blurbs) than a comment.
jsLavaGoat 3mo ago
I did something similar and called it gitredoxide since I started with gitoxide.
deleted 3mo ago
[deleted]
dstanko 3mo ago
In 15+ years of using Git, I have not had a single crash. What problem are you solving???
- dakolli 3mo ago
  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.
  - Daishiman 3mo ago
    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.
    - dakolli 3mo ago
      [flagged]
- schacon 3mo ago
  A feature complete, reentrant, linkable library. Reading the article often helps with questions like this.
- lelanthran 3mo ago
  > In 15+ years of using Git, I have not had a single crash. What problem are you solving??? The pro-user license (GPL).
- not_a_bot_4sho 3mo ago
  I've seen plenty of crashes over the years. Primary in one private repo where gc and pruning triggered unexpected exits for a fixed duration of time. That said, stability overall has been nothing short of fantastic. And I can't answer the question of "why?" for this particular rewrite.
yanhangyhy 3mo ago
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
dakolli 3mo ago
[flagged]
rockmeamedee 3mo ago
I don’t understand. Gitoxide exists and is great. It might have missing pieces, but it’s easier to vibecode any needed networking additions to Gitoxide (which is maintained) than to just go and burn tokens trying to clone all of git again. Git wants to add Rust. Gitoxide is a multi year project that’s going to be more maintained than an ad-hoc “it says it passes the test” vibeclone. I’m not even against vibecloning things when it’s useful, but this shows no benefits. Git is a beloved tool that few people dislike, it’s not like vinext (people disliking the vendor lock-in they have with nextjs). Also execs should keep in mind that “we burned thousands of dollars on tokens to re-create this beloved software so we can have our own copy”, even without the copyright/licensing argument, just isn’t something positive that the community will react positively to. It doesn’t feel nice to see your favourite works cloned for no benefit. We’re past the “it was an experiment to see how far AI can go” stage now.
- dochtman 3mo ago
  GitButler now employs/has hired the gitoxide maintainer, I think? So no doubt they’re aware. I guess they found that gitoxide isn’t good enough and/or to expensive to extend/improve for their use cases?
  - schacon 3mo ago
    I think Byron (Gix author/maintainer) is one of the most excited people about the Grit project. Gitoxide is great and we will continue to push it forward. Grit is an orthogonal project. Perhaps we can use one in the other or maybe Grit goes nowhere. But we thought that a small investment in a different approach is worth the effort.
- schacon 3mo ago
  As mentioned, we also work on the Gitoxide project and Byron is a member of our team. We are well aware of all large community efforts and we're also cohosting the Git Merge conference this year. There is a recent effort to vibe-loop more Git into Gitoxide, which is interesting: https://github.com/GitoxideLabs/gitoxide/pull/2538 https://github.com/GitoxideLabs/gitoxide/pull/2538 I still think that this is a project that can have value with a little more work. This announcement is merely a milestone, not the end product. I wasn't sure it was really possible to do, even halfway through the project. There has been a lot learned and there is a lot to learn, but I think there are useful applications for both a high quality, hand crafted, opinionated partial Git library (Gix) as well as a vibed, fully implemented, partially sloppy LLM Git library (Grit). We think it's worth exploring and investing in both options for now. Also, I am the exec involved and I've done quite a lot for the Git community over the years. I would never try to have my "own copy" of it, that's ridiculous. I wrote and open sourced the Pro Git book (https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2) and Git community book before it (https://schacon.github.io/gitbook/index.html https://schacon.github.io/gitbook/index.html), I created the official Git website (https://git-scm.com https://git-scm.com), I cofounded GitHub which hosts nearly all open source in the world, I have evangelized and supported the Git ecosystem for almost 20 years now. I restarted and funded development of libgit2 15 years ago, which you could similarly argue was an exec trying to have our "own copy" of Git under a more permissive license and would have been a similarly ridiculous argument.
GreenDolphinSys 3mo ago
This is simply plagiarism of GPL-licensed code, and license-washing as well. I can understand working backwards from a test suite, but this literally just reads the original source: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#source-of-truth https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou... LLM users seem to live in another world where stealing everything that isn't bolted down, and passing it off as their own work, is acceptable.
- schacon 3mo ago
  I see it differently. I look at it as if I had written this code myself, using this same approach. Look at the docs, look at the tests, look at the source, implement something that is interactively compatible but a very different approach. For example, this is exactly what I did when I tried to get SSH commit signing working properly in GitButler: https://blog.gitbutler.com/signing-commits-in-git-explained https://blog.gitbutler.com/signing-commits-in-git-explained You can see in the post that I dug through the C source to figure out how it was canonically done and then implemented something that accomplished the same thing in Rust but without copying source code. There are some similarities between the Grit Rust source and the Git source, but it's mostly around time/formatting type things or byte offset type things needed to make packfile parsing and whatnot work, but as far as I can tell, there is no straightforward copying of code. The approach needed to make this a reentrant, memory safe, library driven codebase is so different that copying is generally not useful. But nobody can _guess_ how packfiles or reftable binary formats are specified, since they're not really documented. I'm aware of this because I'm pretty sure I _personally_ am one of the only ones who has ever attempted to document the packfile binary format: https://schacon.github.io/gitbook/7_the_packfile.html https://schacon.github.io/gitbook/7_the_packfile.html You have to read the source. Which means that libgit2 and Gitoxide and every other Git reimplementation is also "license-washing" per this definition because they also had to reference the Git source to see what the technical specification is. If you find any code in Grit that is clearly line-for-line copied, please point it out and I will replace it. But the Git source is the Git specification and every reimplementation, LLM or not, is forced to use this approach to build anything compatible.
  - 3mo ago
Herbstluft 3mo ago
Is there a term yet for Rust projects rewriting GPL code to get it under non-gpl licenses? Rustwashing?
- ninkendo 3mo ago
  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.)
- witx 3mo ago
  Stealing is the word you're looking for
rbbydotdev 3mo ago
This is great, does it work in the browser via wasm? There’s an emcripten libgit2 out there but the wasm is a little big too be any fun
- schacon 3mo ago
  Not yet. I have a PR with a WASM experiment based on an earlier build, but it's not integrated. It's on my list of things to try. I _did_ get it working for some things, so it's clearly possible, but I need to put some more effort into it.
csomar 3mo ago
> Another possible use case is a WASM build that could be used to do a super wide range of interesting things. Run nearly any Git command in an edge Vercel function for example. Or maybe you could build things like Cloudflare Artifacts without relying on partial implementations like isomorphic-git but instead a fully compliant WASM build of Grit. > You had me at WASM... What does this mean? Does the OP want us to convert his AI-vibed code to a WASM-compatible build? Does the OP even understand what that entails?
theknarf 3mo ago
Why not just rewrite the networking part of gitoxide with an agent? Wouldn't gitoxide already be 90% there for your usecase? Why slopfork all of git?
sepisoad 3mo ago
i wish there was an option in hackernews so i could filter out such crappy titles! DUH
konovalov-nk 3mo ago
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.
tstansel 3mo ago
The section about handoffs being frustrating is the same thing ive experienced and why i built https://github.com/TStansel/handoff https://github.com/TStansel/handoff. Goal is to be able to transfer context from one agent to another when switching which provider is being used. So when i hit usage limits on claude i can can run handoff claude codex and codex is given a md file to start from and continuing working. Still early but ive found it useful in my daily flows already!
Footprint0521 3mo ago
$10-15k in tokens??? Holy frick someone tell this man about deepseek-v4-pro and quick
socratic_weeb 3mo ago
Of course it has the MIT license, when the original was GPL. To hell with these Rust rewrites!
explodes 3mo ago
The license change is more than just concerning. This isn't the first time it happens, and won't be the last, without legal action.
lanycrost 3mo ago
Never had even single issue with the git for a 10 years, doesn't see real reason to switch to this :D

178 points by cbrewster 3mo ago

I continue to be surprised by the lack of understanding around copyright law when it comes to AI.

rvz 3mo ago

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

insanitybit 3mo ago
So .7% tests fail therefor it was 100% a waste of time?
- Zopieux 3mo ago
  Regardless, what's the point?
  - tonymet 3mo ago
    maybe it's an academic project. proof they could reimplement something useful & complex?
  - sharkjacobs 3mo ago
    > 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). > Having parts of Git as discrete, embeddable slices of library also enables things like building custom Git servers or client functionality in Rust. > 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.
  - insanitybit 3mo ago
    The article starts out with paragraphs about the history and motivation. > it made me wonder about the feasibility of using that same approach to accomplish something I've been dreaming about for 15 years now, > which means that it's difficult to use it in long running processes without fork/exec overhead for everything. > 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
- rvz 3mo ago
  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.
  - sharkjacobs 3mo ago
    > 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.
- fg137 3mo ago
  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.
bryanlarsen 3mo ago
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. 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.
ianm218 3mo ago
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 https://github.com/rustls/rustls https://github.com/rustls/rustls. It is reasonable to make a new implementation and leave behind a bit of baggage.
gpm 3mo ago
> Why not 100%? From the article > 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.
MBCook 3mo ago
The author actually estimated $10-$15,000 worth of tokens.

tonymet 3mo ago

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.

schacon 3mo ago
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.
- tonymet 3mo ago
  grep didn’t indicate anything interesting. S/n was very low. Thanks.

heyts 3mo ago

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

jamesfinlayson 3mo ago
> 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.
- jordand 3mo ago
  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-answers-1-2 https://unknownworlds.com/en/news/spark-engine-questions-and...
  - jamesfinlayson 3mo ago
    Ah my mistake - I know they ditched Source to pursue their own engine and thought they were going all in on Lua, but doing the whole engine in Lua would have been a struggle I think.
MBCook 3mo ago
> 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?

fg137 3mo ago

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

gpm 3mo ago
It'd seem weird to plan to use this until the readme stops saying > 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. Right now it's someone else's experiment that is still in the "might or might not pan out" stage. 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.
- schacon 3mo ago
  I would not use this except to help us test it if interested. I'm announcing it because it's interesting and a milestone in the breadth of test coverage it can pass. It almost certainly cheated on a bunch of those tests and is not feature complete yet. The author of gitoxide is also working on GitButler (who worked on this project) and we're pushing both projects forward and actively using and developing Gitoxide as well. This is simply a different and hopefully complimentary approach to the same problem.
  - fg137 3mo ago
    > because it's interesting and a milestone in the breadth of test coverage it can pass. Sorry, no. Let me be candid and point out that this has achieved exactly nothing except lighting $8k on fire. Put it this way: if I suggest to my boss, "I want to spend $8k of company money to port git to Rust to just see how many tests can pass in that project, even though I don't plan to develop new features with the project, and I don't care about adoption", he is going to shot down the idea in half a second and seriously question my competence.
Yokohiii 3mo ago
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. 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. 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".

Philpax 3mo ago

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

nextaccountic 3mo ago
they would be just wrong. I hope someone with standing sues
- gpm 3mo ago
  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 on the legal decisions on what the copyrightable creative elements in code actually are. 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.
  - Conan_Kudo 3mo ago
    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.
    - joshka 3mo ago
      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?

gdgghhhhh 3mo ago

So, they "decided" it's not a derivative and thus can be listened under MIT instead of GPL....

subygan 3mo ago
a lot of things are just "decided" really. it's just in this case it's the author. we'll have to wait and see who decides to challenge it
madeofpalk 3mo ago
Yeah, that's usually how contracts work. You decide whether you have followed it or not. The other party will decide if they agree. If in dispute, you go to a judge and they decide also.
- cmrdporcupine 3mo ago
  Where's the crowdfunded lawsuit I can donate to?

huflungdung 3mo ago

[dead]

imoverclocked 3mo ago

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?

fg137 3mo ago
In 6 months, seeing no adoption, move the repo to maintenance mode. Archive in 12 months.
Yokohiii 3mo ago
He will be probably super happy for starring the project.
0x000xca0xfe 3mo ago
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.
schacon 3mo ago
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.
- witx 3mo ago
  I won't touch relicensed code even if you payed me. This is morally, if not legally, wrong.

ianm218 3mo ago

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. [1]. https://github.com/ianm199/lua-rs/tree/main https://github.com/ianm199/lua-rs/tree/main Lua [2]. https://github.com/ianm199/valdr https://github.com/ianm199/valdr Valkey/ Redis [3]. https://github.com/ianm199/nginx-rs-port 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.

jabwd 3mo ago
Yeah I got one, why? You aren't learning anything, you are just copying code from other codebases and smashing it together to make some nginx-rust thingie... for what actual goal?
- ianm218 3mo ago
  Well the biggest goal was to be useful. Nginx serves ~20% of the web, memory unsafe languages might just become untractable for critical exposed to the web infra if the rate of critical CVE's on these rises faster than they can be patched, so a drop in replacement would be a big deal in that world. But in terms of learning I'm learning relatively little about how to type Rust into an editor but a lot about how to set up agentic loops that can autonomously get tests to pass and improve performance. For example if you just tell a frontier model (gpt5.5 or Claude Code 4.8) to make some portion of the tests pass they will take forever and just bang their heads against it. I developed a framework to mimic a lot of these tests in nginx... but in minimum non blocking ways so you can run many in parallel with short feedback loops. Similar for performance - how to make tons of performance benchmark and expose maximum telemetry for agents to go and analyze the hotpaths etc.

dabedee 3mo ago

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.

joshka 3mo ago
I think you're saying that you don't believe in the freedoms to use the GPL licensed test suite for certain purposes which are explicitly allowed by the GPL. You don't get to choose a license and then add extra terms to it when you don't feel like it's up to scratch. That's something explicitly not allowed by the GPL license.
- MBCook 3mo ago
  Where does the GPL say you have the freedom to relicense code or derivatives under MIT by fiat? Isn’t having to stay under the GPL a very big part of the GPL license?
  - joshka 3mo ago
    > Where does the GPL say you have the freedom to relicense code or derivatives under MIT by fiat? The first part of this sentence (where in the GPL) is unreached if the second part of it is unmet (relicense code or derivatives) which I contend it likely is. You're begging the question. However: > The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work earlier: > A “covered work” means either the unmodified Program or a work based on the Program. It's that element that would be difficult to prove "work based on the Program"
    - trumpdong 3mo ago
      Asking an LLM "here's a thing, rewrite it in Rust" is pretty clearly creating either a derivative work or a different form of the same work, just like asking a transpiler would.

Aperocky 3mo ago

> 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. 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-agentic https://aperocky.com/blog/post.html?slug=unix-philosophy-age...

Levitating 3mo ago
You cut that citation conveniently short. > 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.
- Aperocky 3mo ago
  Added it in full. It still squarely falls under "this is for fun/are you seriously doing this for this purpose" territory for me. 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.
  - schacon 3mo ago
    My intent with this project is not to replace Git in any way. I don't care about the CLI part of this project. 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.
    - 3mo ago

boredatoms 3mo ago

Theres already git-in-rust project that is making good progress https://github.com/gitoxidelabs/gitoxide https://github.com/gitoxidelabs/gitoxide

jauntywundrkind 3mo ago
Gitoxide is mentioned in this write up, yes, > 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.
schacon 3mo ago
Gitoxide is also developed primarily by Byron, who also is part of the GitButler team. We're pushing both projects forward.

dabedee 3mo ago

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.

schacon 3mo ago
GitButler's source code is available, so we're not asking you to trust us much at all. https://github.com/gitbutlerapp/gitbutler https://github.com/gitbutlerapp/gitbutler
- deleted 3mo ago
  [deleted]
- deleted 3mo ago
  [deleted]
- ersatz-matty 3mo ago
  That's great because we don't.

ewy1 3mo ago

pretty dystopian to ask a robot to recreate your favorite software just so you can relicense it for your business venture

schacon 3mo ago
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.
- 201984 3mo ago
  >We're choosing a license that is usable by the entire community. What a weaselly way to put it. 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.
  - cmrdporcupine 3mo ago
    I love how he uses the word "community", effectively washing away what is really happening which is taking a community protected asset and turning it into a corporate one. Ok, my coffee just kicked in and I'm incensed. Might go do an FSF donation.
- jraph 3mo ago
  > Our goal is a linkable library, which makes GPL impossible 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. 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).

squidsoup 3mo ago

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

Yokohiii 3mo ago
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 to anyone. If they actually train models on their IP, anyone could implement their APIs and slap a GPL license on it. At that point, things will get very interesting.
- dakolli 3mo ago
  No one is training their models on their closed sourced proprietary code. They own github, why would they need to do this.
  - Yokohiii 3mo ago
    More is better.
- wongarsu 3mo ago
  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
  - Yokohiii 3mo ago
    Yes but it's illegal to replicate it. A different story if LLMs lift license restrictions.
trumpdong 3mo ago
They were already quite meaningless since nearly every FOSS copyright owner doesn't sue violators.

anonova 3mo ago

Grit was the name of a _Ruby_ implementation of git way back when: https://github.com/mojombo/grit/ https://github.com/mojombo/grit/. I believe it's actually what GitHub was built on then.

Yokohiii 3mo ago
Okay name is taken. Let's rename it to Grift.
mojombo 3mo ago
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!
schacon 3mo ago
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. :)

stefanha 3mo ago

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

schacon 3mo ago
I would also be interested. I haven't dug into this at all yet, nor have I tried to optimize the size (or really, anything else). 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).
- andwur 3mo ago
  Looking at just the `grit` executable, 58 of the top 200 largest file->resulting code sources are from clap-rs' derive functionality i.e. it's the command-line parsing. The #1 largest is, surprisingly, merge_trees[1] which comes in at 183kiB final binary size. There isn't so much code in that file that it seems reasonable, so it's potentially one of the derives in use (Debug being a common culprit for bloat) that's blowing it out. After those outliers it starts to level out quickly. Splitting it by crate: `grit` is 13.6MiB, `grit_lib` is 4.8MiB and then it's `std`, `rustls` and `regex_automata` that are the next largest. So as pure library you could hopefully shave off quite a bit of that 25MiB. [1] https://github.com/gitbutlerapp/grit/blob/main/grit-lib/src/merge_trees.rs https://github.com/gitbutlerapp/grit/blob/main/grit-lib/src/...
  - schacon 3mo ago

hankbond 3mo ago

> 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-sabotage-your-app-if-youre-a-competitor.html 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.

usernametaken29 3mo ago

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?

absintini 3mo ago
[flagged]
- galangalalgol 3mo ago
  When we go a full year without a lpe in the linux kernel I'll start considering it...
  - NekkoDroid 3mo ago
    How many of the LPE would rust even fix? They mostly seem logical errors and not memory or threading related race conditions to me.
    - galangalalgol 3mo ago
      This year, none of them. Historically most or all. So that is another caveat. If all future lpe are logic errors I'd start reconsidering the value proposition. I do actually like writing rust though. I don't feel like it slows me down. I also love the simplicity of c vim and gdb, though my first exposure was lattice on the amiga 1000. I wonder if strict typing makes it take fewer tokens to find bugs?
  - absintini 3mo ago
    I mean we’re almost there with Mythos/Fable so there ya go. In two years bye bye rust.

djha-skin 3mo ago

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.

jraph 3mo ago
> 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.
keybored 3mo ago
This looks more like a blog-blurb (if blogs had blurbs) than a comment.

jsLavaGoat 3mo ago

I did something similar and called it gitredoxide since I started with gitoxide.

deleted 3mo ago

[deleted]

dstanko 3mo ago

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

dakolli 3mo ago
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.
- Daishiman 3mo ago
  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.
  - dakolli 3mo ago
    [flagged]
schacon 3mo ago
A feature complete, reentrant, linkable library. Reading the article often helps with questions like this.
lelanthran 3mo ago
> In 15+ years of using Git, I have not had a single crash. What problem are you solving??? The pro-user license (GPL).
not_a_bot_4sho 3mo ago
I've seen plenty of crashes over the years. Primary in one private repo where gc and pruning triggered unexpected exits for a fixed duration of time. That said, stability overall has been nothing short of fantastic. And I can't answer the question of "why?" for this particular rewrite.

yanhangyhy 3mo ago

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

dakolli 3mo ago

[flagged]

rockmeamedee 3mo ago

I don’t understand. Gitoxide exists and is great. It might have missing pieces, but it’s easier to vibecode any needed networking additions to Gitoxide (which is maintained) than to just go and burn tokens trying to clone all of git again. Git wants to add Rust. Gitoxide is a multi year project that’s going to be more maintained than an ad-hoc “it says it passes the test” vibeclone. I’m not even against vibecloning things when it’s useful, but this shows no benefits. Git is a beloved tool that few people dislike, it’s not like vinext (people disliking the vendor lock-in they have with nextjs). Also execs should keep in mind that “we burned thousands of dollars on tokens to re-create this beloved software so we can have our own copy”, even without the copyright/licensing argument, just isn’t something positive that the community will react positively to. It doesn’t feel nice to see your favourite works cloned for no benefit. We’re past the “it was an experiment to see how far AI can go” stage now.

dochtman 3mo ago
GitButler now employs/has hired the gitoxide maintainer, I think? So no doubt they’re aware. I guess they found that gitoxide isn’t good enough and/or to expensive to extend/improve for their use cases?
- schacon 3mo ago
  I think Byron (Gix author/maintainer) is one of the most excited people about the Grit project. Gitoxide is great and we will continue to push it forward. Grit is an orthogonal project. Perhaps we can use one in the other or maybe Grit goes nowhere. But we thought that a small investment in a different approach is worth the effort.
schacon 3mo ago
As mentioned, we also work on the Gitoxide project and Byron is a member of our team. We are well aware of all large community efforts and we're also cohosting the Git Merge conference this year. There is a recent effort to vibe-loop more Git into Gitoxide, which is interesting: https://github.com/GitoxideLabs/gitoxide/pull/2538 https://github.com/GitoxideLabs/gitoxide/pull/2538 I still think that this is a project that can have value with a little more work. This announcement is merely a milestone, not the end product. I wasn't sure it was really possible to do, even halfway through the project. There has been a lot learned and there is a lot to learn, but I think there are useful applications for both a high quality, hand crafted, opinionated partial Git library (Gix) as well as a vibed, fully implemented, partially sloppy LLM Git library (Grit). We think it's worth exploring and investing in both options for now. Also, I am the exec involved and I've done quite a lot for the Git community over the years. I would never try to have my "own copy" of it, that's ridiculous. I wrote and open sourced the Pro Git book (https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2) and Git community book before it (https://schacon.github.io/gitbook/index.html https://schacon.github.io/gitbook/index.html), I created the official Git website (https://git-scm.com https://git-scm.com), I cofounded GitHub which hosts nearly all open source in the world, I have evangelized and supported the Git ecosystem for almost 20 years now. I restarted and funded development of libgit2 15 years ago, which you could similarly argue was an exec trying to have our "own copy" of Git under a more permissive license and would have been a similarly ridiculous argument.

GreenDolphinSys 3mo ago

This is simply plagiarism of GPL-licensed code, and license-washing as well. I can understand working backwards from a test suite, but this literally just reads the original source: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#source-of-truth https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou... LLM users seem to live in another world where stealing everything that isn't bolted down, and passing it off as their own work, is acceptable.

schacon 3mo ago
I see it differently. I look at it as if I had written this code myself, using this same approach. Look at the docs, look at the tests, look at the source, implement something that is interactively compatible but a very different approach. For example, this is exactly what I did when I tried to get SSH commit signing working properly in GitButler: https://blog.gitbutler.com/signing-commits-in-git-explained https://blog.gitbutler.com/signing-commits-in-git-explained You can see in the post that I dug through the C source to figure out how it was canonically done and then implemented something that accomplished the same thing in Rust but without copying source code. There are some similarities between the Grit Rust source and the Git source, but it's mostly around time/formatting type things or byte offset type things needed to make packfile parsing and whatnot work, but as far as I can tell, there is no straightforward copying of code. The approach needed to make this a reentrant, memory safe, library driven codebase is so different that copying is generally not useful. But nobody can _guess_ how packfiles or reftable binary formats are specified, since they're not really documented. I'm aware of this because I'm pretty sure I _personally_ am one of the only ones who has ever attempted to document the packfile binary format: https://schacon.github.io/gitbook/7_the_packfile.html https://schacon.github.io/gitbook/7_the_packfile.html You have to read the source. Which means that libgit2 and Gitoxide and every other Git reimplementation is also "license-washing" per this definition because they also had to reference the Git source to see what the technical specification is. If you find any code in Grit that is clearly line-for-line copied, please point it out and I will replace it. But the Git source is the Git specification and every reimplementation, LLM or not, is forced to use this approach to build anything compatible.
- 3mo ago

Herbstluft 3mo ago

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

ninkendo 3mo ago
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.)
witx 3mo ago
Stealing is the word you're looking for

rbbydotdev 3mo ago

This is great, does it work in the browser via wasm? There’s an emcripten libgit2 out there but the wasm is a little big too be any fun

schacon 3mo ago
Not yet. I have a PR with a WASM experiment based on an earlier build, but it's not integrated. It's on my list of things to try. I _did_ get it working for some things, so it's clearly possible, but I need to put some more effort into it.

csomar 3mo ago

> Another possible use case is a WASM build that could be used to do a super wide range of interesting things. Run nearly any Git command in an edge Vercel function for example. Or maybe you could build things like Cloudflare Artifacts without relying on partial implementations like isomorphic-git but instead a fully compliant WASM build of Grit. > You had me at WASM... What does this mean? Does the OP want us to convert his AI-vibed code to a WASM-compatible build? Does the OP even understand what that entails?

theknarf 3mo ago

Why not just rewrite the networking part of gitoxide with an agent? Wouldn't gitoxide already be 90% there for your usecase? Why slopfork all of git?

sepisoad 3mo ago

i wish there was an option in hackernews so i could filter out such crappy titles! DUH

konovalov-nk 3mo ago

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.

tstansel 3mo ago

The section about handoffs being frustrating is the same thing ive experienced and why i built https://github.com/TStansel/handoff https://github.com/TStansel/handoff. Goal is to be able to transfer context from one agent to another when switching which provider is being used. So when i hit usage limits on claude i can can run handoff claude codex and codex is given a md file to start from and continuing working. Still early but ive found it useful in my daily flows already!

Footprint0521 3mo ago

$10-15k in tokens??? Holy frick someone tell this man about deepseek-v4-pro and quick

socratic_weeb 3mo ago

Of course it has the MIT license, when the original was GPL. To hell with these Rust rewrites!

explodes 3mo ago

The license change is more than just concerning. This isn't the first time it happens, and won't be the last, without legal action.

lanycrost 3mo ago

Never had even single issue with the git for a 10 years, doesn't see real reason to switch to this :D