etc/reports/25-12.md
And it's the end of the year already, let's dive right into this month's news!
unsafeIn a major effort to simplify zip, I managed to use the new pure Rust API that zlib-rs introduced in v0.5.4, cutting out another dependency to now depend on zlib-rs directly.
It's tangential that gitoxide still encounters issues decoding some pack files that are clearly related to this switch, but with some luck these will go away when this fix lands.
Otherwise, I might have to bring back zlib-ng as fallback option at least temporarily, but I have hopes that this won't be necessary after all.
While some respond allergic to it, I started to fully embrace Copilot reviews. What I find fascinating is that it typically manages to stay away from nonsense, and in the worst case points out typos, grammatical errors, and stale documentation. This property makes it great as a review baseline.
And on top of that, sometimes, it finds real bugs. Like the other day when I once again fell for the usual opt.and_then().or_else() fallacy which isn't always the same as an if condition - and it pointed it out, squelching a bug in its tracks.
Occasionally, it's pedantic, but it's still right and rules are rules, thanks to point out my human sloppiness. And more rarely, it's also just wrong (or I don't get it), but it's still very much worth it as overall value proposition. It must be noted that for some reason, I have free credits assigned to my account, so thanks GitHub for letting me test this fantastic tool.
In the spirit of using GenAI more with tasks that it's known to be good for, I tasked it to improve the baseline tests from about 60% success rate to full compliance.
And this worked well, notably also after removing the url crate as dependency to cut off a whopping 60 crates.
Here the task was to merely improve the built-in parsing capabilities to parse more of what Git can parse, based on its own tests. Once again the baseline is created by Git itself to ensure we can parse them.
Interestingly, this is a case of 'better is better even though it's not perfect', as I didn't take the time to validate the pros and cons or even completeness of the approach. Instead, it's just better than before with a clear entrypoint for the fully generated parsing code, so it will be no problem to refactor it later, maybe based on how Git is actually doing the parsing.
Something I am thinking about is to have an approach where the Git way of parsing relative URLs is fully converted to Rust, with the C code as reference. For now, I have to refrain from doing that though as whatever happens next, it will certainly take way more time than I currently have as it does require much more diligence to take it to full compliance.
gix-archive without zip crate in favor of rawzipThanks to a pointer from the community I was made aware of the zip dependency in gix-archive being unmaintained, and it turned out that GenAI could one-shot the transition to rawzip, which uses flate2 as plug-in encoder. It was a pretty painless experience, and the code seems to be spot on, particularly after a small refactor.
:(optional) paths in Git configurationFor a moment I wanted to attribute this implementation to myself when I remembered that in fact it was also trampolined by GenAI, for a first implementation of the plumbing. That way, we now support configuration like this:
[section]
path = :(optional)/path/might/not/exist
What was left for me to do besides the usual refactoring was to wire this feature up to the gix create, which now will check if the path is optional, and if so, return None if the underlying path isn't accessible. That way the caller doesn't have to know anything about it, it's completely transparent.
Maybe a small thing, but it can make the difference between everything works and utter strangeness: improved detection of how executable bits are represented by the filesystem. Maybe a more recent change in Git, but now gix-fs will probe the filesystem very similarly.
gix-transport and gix-protocol cleanup - continuedThanks to the continued efforts of Dirkjan Ochtman, more and more of the gix-protocol and gix-transport layer became additive. Admittedly, I don't have an overview or tracking issue to know what is missing, but for now I am entrusting myself with Dirkjan and hope he will keep the PRs coming until he can declare complete victory.
Thanks a lot!
gix blame diff-slider: the Second RoundWe now have access to imara-diff v0.2 behind a feature toggle in gix-diff, to allow gix-blame to experiment with its implementation. The diff-slider tests that were introduced previously went from something around 5% to 95% in an instant, showing the slider implementation in imara-diff is quite close to what it needs to be, assuming gix-blame is a perfect recreation of the algorithm, and assuming that imara-diff itself is providing the same diffs as xdiff, the engine powering Git.
On the bright side, it looks like these 95% compatibility would already satisfy most users, so the next steps here would be to integrate imara-diff v0.2 as default by porting our own UnifiedDiff implementation to it.
It's notable that I plan to keep imara-diff v0.1 for a while longer as well to power the line-counting, which can then in theory at least be done with less allocations.
The biggest hurdle for our gix blame implementation and the gix diff implementation for that matter is the lack of diff-slider compatibility with Git.
Thanks again to Christoph Rüßler for pushing this topic forward!
And as merely a filler task for Christoph Rüßler, we can be looking forward to gradually more work done towards SHA256 support. The general idea is to make the codebase at least compile with the new hash format, and then, step by step, adjust all relevant tests to also run in SHA256 mode.
The latter will be a major undertaking, but we will try to learn from Git and be smart about it, and enable running the full test suite in both SHA1 and SHA256 mode.
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 (see theGitButlerparagraph for details).
Cheers Sebastian
PS: The latest timesheets can be found here (2025).