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

Bun's attempted to integrate with libgit2 instead of spawning calls to the git CLI and found it to be consistently 3x slower iirc

The micro-benchmarks are for the internal git operations that bun rn delegates to CLI calls. Overall, network time (ie round trip to GitHub and back) is what balances the performance when evaluating `bun install` but there are still places where ziggit has better visible wins like on arm-based Macs https://github.com/hdresearch/ziggit/blob/master/BENCHMARKS....

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)

I cross-posted to my personal blog too https://yev.bar/ziggit

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

maintain a separate git implementation

If git were a rapidly evolving project then I'd think this'd be a stronger issue.

With git being more of an established protocol that projects can piggy-back off of from GitHub to jj, filling a library in a new language seems like something that contributes

We recently updated our LSD MCP server to be able to control a local browser as well as accomplish function interpolation via MCP tools.

For a more serious showcase of how this looks: we turned scraping Substack metrics data into a simple zod/TypeScript project:

https://x.com/getlsd/status/1919808557115179414

Feel free to reach out with issues or requests to yev at lsd dot so

Hey HN,

We made a dynamically typed programming language specifically for interacting with web browsers and made a parody of the song "No Type" by Rae Sremmurd to accompany our TypeScript SDK

For a longer video https://www.youtube.com/watch?v=s97G-E46-Yo

Some options:

- Don't use the python package at all - Get a second macbook solely for automated iMessaging - Review the code before disabling/installing

If you don't care that much about programmatically getting blue bubbles then this post isn't for you

Thanks! Re "what would be some use cases for this", there's obviously an unbounded limit to what can be done based on data fetched from the internet and our focus is more on making the time between "getting data" and "extrapolating from said data" as minimal as possible