This month feels like one of these summer months when not much has been happening, despite me being busy as usual.
However, there have been contributions with one being very exciting in particular.

## Community

### Better Release Handling

Thanks to [Eliah](https://github.com/EliahKagan) creating new releases and triggering a release build is now easier than ever with `just roll-release`. Thanks to him, we finally figured out why the release build isn't triggered just when pushing tags. It turns out that pushing more than 3 tags at once won't trigger individual events anymore.

There probably is a good reason for that, but it did confuse me a lot, particularly since this breaking change was made sometime in the past without notice or any indication that it actually ignored event generation - more than an hour of my life went into trying to figure this out for sure.

In any case, I could also imagine that `cargo smart-release` could one day learn to push top-level tags separately from plumbing tags, but until that day `just` will do fine.

### An iterator over Pseudo-Refs

It's now also possible to traverse refs in the root of the Git repository with `repo.references().pseudo()`, thanks to [a recent contribution](https://github.com/GitoxideLabs/gitoxide/pull/2061).
This means references like `HEAD`, `FETCH_HEAD` or similar `*_HEAD` can now be explored by traversal.

A recent conversion with [Patrick Steinhardt](https://about.gitlab.com/blog/authors/patrick-steinhardt/) about the matter revealed that in the way it's implemented, the method name is a misnomer as it technically traverses the recently termed *Root References*. Pseudo-refs are actually only two references, `FETCH_HEAD` and `MERGE_HEAD`, as these contain additional information despite being readable as simple references as well.

Breaking change incoming 😅.

### RefTable support is incubating

In that same conversation with [Patrick Steinhardt](https://about.gitlab.com/blog/authors/patrick-steinhardt/) we also decided to work together on bringing RefTable support to `gitoxide`. The idea is to just sit down and get started, him teaching me the format, and me assisting to get started with an idiomatic Rust implementation.

Can't wait to see this come to fruition, as it turns out RefTables will be the default in Git 3.0, along with SHA256 as default.

### `gix tag list`

Thanks to [Christoph Rüßler](https://github.com/cruessler) we now have a first and very simple way of listing tags, with the specialty of making clear which tags are annotated (i.e. points to a `Tag` object).

I also hope that one day it can learn to auto-sort by semantic version, as that would allow me to use it in place of `git tag --sort='version:refname'`.

### Native `russh` based SSH transport is incubating

And [here is the PR](https://github.com/GitoxideLabs/gitoxide/pull/2081).

This is quite an undertaking but apparently the current implementation level already manages to complete a handshake successfully.

And this is already all I know as I didn't have the time yet to disect it sufficiently. Getting this ready for production and protecting it from regression is going to be major effort though, and regression tests to me are an unsolved problem given how elaborate a test-setup would have to be.

My hope is that we can wire it up to `gix` right away so journey tests could be used for simple SSH transport tests.

It's early days here though, and I am sure you will hear more about it as it progresses.

### Zlib-rs is now the default

I don't actually know if it was mentioned sufficiently already, but thanks to [Josh Triplett](https://github.com/joshtriplett) many projects now use `zlib-rs` as default way of dealing with zip streams. `zlib-rs` is essentially `zlib-ng` written in Rust, and it solved a couple of portability and toolchain problems, while reducing complexity in our Cargo manifests as zlib-related feature toggles can soon be removed.

### Gix in Cargo

It took some pushing (of myself) to finally get [`cargo package` PR](https://github.com/rust-lang/cargo/pull/15534), and I can't wait for it to pass the review for more correctness during `cargo package` change detection, and at least 25% more performance thanks to faster dirty-files checking.

Assuming this will be getting merged soon, I'd actually have nothing in the pipeline for Cargo anymore, with no obvious candidate in sight. However, when `git reset` is implemented, plenty of Cargo interactions with local Git clones could also be converted to Git.

Cheers
Sebastian

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