yevbar

I'm actually assured to hear the git CLI is better covered than libgit2 since the CLI test suite is what I used as my "validation" for progress on meeting git's functionality

As for what happened with Bun and libgit2, my best guess honestly is smth to do with zig-c interops but don't doubt there are optimizations everywhere to be done

If this were 2+ years ago perhaps, with industry adopting more agents in their SDLCs (ie Stripe minions or Ramp background agents), I think we're more a matter of time before we treat agent/human built products the same unless we're branding smth as artisanal human-crafted software

> Sure, if you have a complete test suite for a library or CLI tool, it is possible to prompt Claude Opus 4.6 such that it creates a 100% passing, "more performant", drop-in replacement.

This was the "validation" used for determining how much progress was made at a given point in time. Re training data concerns, this was done and shipped to be open source (under GPLv2) so there's no abuse of open source work here imo

Re the tradeoffs you highlight - these are absolutely true and fair. I don't expect or want anyone to just use ziggit because it's new. The places where there performance gains (ie internally with `bun install` or as a better WASM binary alternative) are places that I do have interest or use in myself

_However_, if I could interest you in one thing. ziggit when compiled into a release build on my arm-based Mac, showed 4-10x faster performance than git's CLI for the core workflows I use in my git development

This was orchestrated and developed by agents with verifications like the codebase compiling or git's CLI test suite passing.

That was so the commit authors don't all appear like blank accounts on GitHub

The original target was bun since it itself is written in zig, not because of anything specific to the language

When it was clear that there were benefits in filling in more of git's capabilities (ie targeting WASM), I then went and filled in more git features.

It's not by any means a universal win over everything but it does have notable wins like having git operations be between 4-10x faster on arm-based MacBooks than git itself

The reason being bun actually tested both using the git CLI as well as libgit2. Across the board the C library was 3x slower than just spawning calls to the git CLI.

Under the hood, bun's calling these operations when doing a `bun install` and these are the places where integrating 100% gives the most boost. When more and more git deps are included in a project, these gains pile up.

However, the results appear more at 1x parity when accounting for network times (ie round trip to GitHub)

Edge cases certainly apply with scripts depending on specific git CLI args or stdout strings may not suffice with ziggit.

_However_, for the use cases that most developers or agents are looking for, ziggit should have enough features covered. Happy to fix issues or bugs if that's not the case

I ran the test suite specifically for git's CLI as that was the target I wanted to build towards (Anthropic's C compiler failed to make an operating system since that was never in their original prompts/goals)

The way it gets organized is there are "scripts" which encompass different commands (status, diff, commit, etc) however each of these scripts themselves contain several hundred distinct assertions covering flags and arguments.

The test suite was my way of validating I not only had a feature implemented but also "valid" by git's standards