101–110 of 318 posts
Earlier quoted context omitted.
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.
Thanks.
Earlier quoted context omitted.
Medium, substitutibility, basics of copyright law.
Fair point on medium - this was a lazy example. Substitutibility probably doesn't apply here in the way you're implying and if it did it would likely be hampered by the 9th circuits findings about transformation in sony v connectix. Arguments here likely would look at rust not having a stable ABI, and hence not being inherently substitutable as a libray (grit-lib), less clear as an executable (grit-cli) on that side…
Earlier quoted context omitted.
> They all seem to be rewrites for the sake of "performance". And yet this performs dramatically worse. A slower, untested, incomplete git implementation, all for the low low price of $10-$15,000. And don’t forget it wasted a bunch of human time in the process. So if someone mentioned somewhere else there is already a Rust port a group is doing somewhere. How much could they have accomplished with this much money and…
It's not for performance, it's for Rust. If the first stereotype of Rust programmers is announcing that a project is in Rust before any other desirable software property (e.g. stable, performant, etc), the second stereotype is that Rust programmers love rewriting stuff in Rust, just for the sake of Rust. (The 2.a. corollary is that they love rewriting GPL projects specifically and downgrading them to MIT/Apache)
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.
This project is entirely about providing a feature complete (even if sloppy) library implementation of Git, which does not otherwise exist.
> 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 s…
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).
Earlier quoted context omitted.
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.
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.
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.
Earlier quoted context omitted.
> That's not actually the case at hand here - the agents were given the original source to reference: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou ... yeah fair - the "The canonical Git source code we're targeting to replicate the functionality of is in the git/ subdirectory." part makes this hard to argue against. > To the extent the resulting work is a derivative of the test suite it is possibly inf…
Writing fn sum(a: u8, b: u8) { a + b } Doesn't infringe upon copyright period, because there's no creative element in that work. Imagine a more substantial example though. Perhaps you have a test that checks that some file written in a binary format is correct, and gives names (creative elements) to each field of the format that it prints when you mess up the field, and has comments describing why the bytes are laid…
There's likely a threshold at some point. It's helpful to look at a minima and then continue from there though.
I'm curious if there's case law that supports your assertions here?
> A pretty fun experiment and I think we can shape this into something truly useful to the whole community. Agree with first half of this sentence, we should all have fun with experiments. > It was never based on a linkable and reentrant library, but instead on a "Unix" philosophy of chaining together simpler commands, which means that it's difficult to use it in long running processes without fork/exec overhead for…
Isn’t git already just an interface over libgit? How is that different?
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.
I’m all for memory safety and such but honestly what’s the use case for this? Showing off agentic development? In 10+ years git has never failed on a memory overflow or else. Sometimes software is “good as is” and I’m pretty confident git classifies as such. I’ve also never really hit the limitations of git, even with teams of 20+ developers and lots of binary artefacts. You got to really stretch git limitations, in…
I addressed this in the post, but Git has no linkable library and never has. If you want to do even something small, you need to fork/exec a process and communicate with it via stdin/out. Or completely reimplement it and all of the edge cases - for example, reading even one object can be either loose (easy) or in a packfile (much more difficult). Reading a reference (what SHA does a branch point to) can be in a loose…
Earlier quoted context omitted.
Fair point on medium - this was a lazy example. Substitutibility probably doesn't apply here in the way you're implying and if it did it would likely be hampered by the 9th circuits findings about transformation in sony v connectix. Arguments here likely would look at rust not having a stable ABI, and hence not being inherently substitutable as a libray (grit-lib), less clear as an executable (grit-cli) on that side…
The test suite could test aspects of the architecture/design of the codebase that are not necessary for interoperability and constitute novel expression of a piece of software in a way that is not at all language specific.
Does anyone plan to use this? 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 > 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…
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.