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

▲

gpm 2 hours ago | parent | next [-]

> 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 3 hours ago | parent | prev | next [-]

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

▲

fg137 3 hours ago | parent | next [-]

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 3 hours ago | parent | prev | next [-]

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 3 hours ago \| parent [-]
		> 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 3 hours ago | parent | prev [-]

Regardless, what's the point?

	▲	insanitybit 3 hours ago \| parent \| next [-]
		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
	▲	sharkjacobs 3 hours ago \| parent \| prev \| next [-]
		> 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.
	▲	tonymet 3 hours ago \| parent \| prev [-]
		maybe it's an academic project. proof they could reimplement something useful & complex?

▲

ianm218 3 hours ago | parent | prev | next [-]

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 an hour ago | parent | prev | next [-]

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

▲

bryanlarsen 3 hours ago | parent | prev [-]

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.