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

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

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

maybe it's an academic project. proof they could reimplement something useful & complex?