[rvz]

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

[gpm]

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

[insanitybit]

So .7% tests fail therefor it was 100% a waste of time?

[fg137]

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.

[rvz]

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]

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

[Zopieux]

Regardless, what's the point?

[sharkjacobs]

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

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

[tonymet]

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

[ianm218]

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. It is reasonable to make a new implementation and leave behind a bit of baggage.

[MBCook]

The author actually estimated $10-$15,000 worth of tokens.

[bryanlarsen]

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.