etc/reports/26-05.md
The broken window theory seems quite true to me, now that it's the second month in a row that I miss my 22nd of the month deadline. It is my hope is that this won't happen again anytime soon as I should now be more relieved of feature pressure, but we will see.
My head is fuzzy, so much happened and so much still is to happen. Too many open PRs, usually one-shot issue fixes that still wait for a review. Then most of my time went elsewhere. Too many emails still to catch up on, it's probably going to take a week or two just to get down from 30PRs to closer to zero. Of course it's safe to say that the amount of contributions went through the roof, after all, there is no barrier to entry anymore. And all that shows, but it's also exciting, as a challenge to deal with. When it comes to handling PRs the biggest new skill to master is to decide which ones to redo with my own prompts. And while writing this I convince myself to redo most of them by default to have something to compare. Maybe there should be a skill for that… but I digress.
And I did it again! There was a version upgrade of winnow whose type transpired through a public API, without marking this as breaking change, so the patch release of a plumbing crate would break the previous release.
This time, I went in with a chainsaw to fix this problem for good. Thanks to Codex I wasn't only able to remove the winnow type from the public API, I could replace it entirely with standard imperative Rust parsers. And while at it, some missing fuzzers were added, too.
The side-effect? I understand the parser code again and can maintain it, and it's faster, too. It's still heavily influenced from winnnow and passed &mut &[u8], which is a style I come to like as well.
v0.83 is the fix, v0.82 is yanked, it just took a weekend. Worth it.
After the last month was all about fuzzers and security fixes, this month was about fixing the fallout of OSS-Fuzz reports. Particularly pack and Git index files are now so much more resilient, it's incredible what the fuzzer can do.
Is gitoxide now invulnerable? Time will tell. Is it better than Git in that department?
It's hard to imagine that it isn't, but then again, I'd be surprised if Google-OSS-Fuzz isn't just as busy with Git as it is with gitoxide.
And it has happened: SHA-256 is now available in gix for reading and writing. It's notable that this doesn't include the transport and protocol layers, which probably just awkwardly fail right now.
Downstream users will still have to enable the sha256 to get it, with the note that this will increase the memory footprint of the gix::ObjectId accordingly, which matters for some operations more than for others.
gix-testtools aren't so special anymoreTo handle a cyclic dependency due to its .gitignore support, it couldn't refer to in-workspace dependencies. And those crates that would cause a cycle then needed to offload their tests into a separate crate to be able to use it, or back-in-the-days rust-analyser would choke.
Finally, I was able to address this by making the usage of the workspace crates optional. And when an in-workspace crate that would cause a cycle needs to use it, it will fallback to a hand-rolled version of basic .gitignore support.
That way, gix-testtools can easily be published each month, and the extra test-crates could be removed, no special-casing needed anymore.
Christoph Ruessler definitely stays on top of the topic with me clearly being the review bottleneck! I will catch up, and we will keep pushing towards making it work for the transport and protocol layers, too! In any case, thanks for your continued efforts!
Aaron Moat landed a fix for a long-standing ctime/mtime flip when decoding index entries. This was most baffling as no test really caught it,
and gix status also was fine. Along with it, there were improvements to the handling of the untracked cache, which can be used to speed up the discovery of untracked files considerably, particularly on Windows.
There is nothing new here, but let's keep the horizon active:
With GitButler slated to have its checkout driven by a tailor-made implementation of 'reset' in
gitoxide, this coincidentally is exactly what Cargo would need to also greatly speed up its checkouts and make them more compatible, too. We are talking proper Git filter support, and speedups in the realms of ~7x.
Cheers Sebastian
PS: The latest timesheets can be found here (2026).