Hacker News Reader

Comment by rvz | Hacker News Reader

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

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

View on HN

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

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

Regardless, what's the point?

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

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

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

Given the author already admitted that the implementation was slow anyway, you are no better off of using gitoxide instead and that has support for Windows where-as Grit does not.

> Currently both Gitoxide and libgit2's networking functionality is either partial, slow or non-existant. Both GitButler and Jujutsu rely on forking out to Git in order to push or pull data. A big reason for this is the incredibly complicated credential logic involved, but all of this is (theoretically) currently covered in Grit.

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.

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.

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

It depends whether the 0.7% failures are testing deliberately unimplemented features like email or is in corner cases in implemented features. It sounds like it's at least mostly the former, hopefully it's 100% the former.

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.

Reply on news.ycombinator.com