And it's the end of the year already, let's dive right into this month's news!

## Zlib-rs: now used in pure Rust and without `unsafe`

In 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](https://github.com/trifectatechfoundation/zlib-rs/pull/449) 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.

## Gen-AI: Copilot reviews

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.

### Url Parsing: full compliance as tested

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.

### Date Parsing: support for more formats

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 `rawzip`

Thanks 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 configuration

For 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:

```gitconig
[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.

## Community

### Improved probing of executable bits

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

Thanks to the continued efforts of [Dirkjan Ochtman](https://github.com/djc), 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 Round

We 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](https://github.com/cruessler) for pushing this topic forward!

### Incubating SHA256 support

And as merely a filler task for [Christoph Rüßler](https://github.com/cruessler), 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.

### Gix in Cargo

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 the `GitButler` paragraph for details).

Cheers
Sebastian

PS: The latest timesheets can be found [here (2025)](https://github.com/Byron/byron/blob/main/timesheets/2025.csv).
