26 03

I feel like I didn't get to work on gitoxide at all, with what feels like 15 PRs waiting for review. Review time is seriously at its limit right now and I have no solution. These days everything goes into GitButler, and LLMs are the reason I am completely maxing myself out. Taking only a day per month for gitoxide isn't enough, and I have to try to make it closer to half a day per week at least while inbound PRs are so numerous.

Oh boy, did the sea change

While I was hesitant and resistant towards LLMs, associating them mostly with AI slop in the programming space, at this time I also had made none of my own experience. And then came a paid-for trial of Opus 4.5, it took 3 days of moderate API usage, 250USD to completely hook me on the juice. Then I tried Codex, and since then I…

• …switched to a Codex Max subscription so I never run out of my intelligence augmentation
  • this feels similarly important like the time when I swapped every programming language for Rust, which just was a huge boost allowing me to focus much more on what matters
• …changed my IDE from RustRover to a customized Zed to optimise my review workflow and have a delightful experience for when I write text.
  • reviewing is the key to staying onboard with the code that now is written for you.
  • I had no idea I was so accustomed to my color scheme, not having it felt wrong for a while. Now I use the default light mode to keep it simple
• …changed my Terminal from Alacritty + Zellij + Zsh to Ghostty + Fish for better responsiveness and comfort. Codex still feels like a slog im comparison, but much less so than Claude which to my mind is just very bad software.

There is still a lot to figure out and improve, particularly my abiltiy to deal with my emails and prioritize work. But I have a feeling that LLMs can help me in various ways.

A small but useful addition to: gix::Repository::reload()

To better support long-running applications and long-lived instances of gix::Repository, and for the lack of more time for smarter solutions, there now is a Repository::reload() method that does as it says. It re-opens with exactly the same open settings that the original instance was opened with, which isn't super trivial to do right. Most importantly, it reloads the configuration which is the main reason this was added, but it's also a good way to drop system resources and caches to start fresh.

ein t hours -p now accounts for shared authorship better

ein t hours -p also learned to respect Co-authored-by trailers, pass them through the mailmap, and deduplicate identities along the way. It's definitely a niche improvement, but it turned out to be needed for my new way of working, putting me firmly into the Co-authored-by message trailer 😅.

gix status learns another corner case

There was also another one of those status fixes that sound impossibly specific until one realizes that real-world usage will eventually find exactly these kinds of cases: assume-unchanged submodule paths replaced by symlinks are now handled correctly as well. It's the kind of case that is non-obvious despite trying my best at the time to not miss any subtleties. On the bright side, now there is a test so the requirement is captured properly.

Community

SHA-256 support: making hash choices explicit

Christoph kept chipping away at SHA-256 support, this time by removing sha1 as the default in gix-hash, with a follow-up that wires explicit sha1 and sha256 feature flags through gix. In that sense this really does feel like a direct continuation of last month's incubation story, only now the emphasis shifts toward making hash selection an explicit compile-time choice for applications and plumbing crates alike.

This way it will be possible to not build SHA1 support for those that want to or have to hard-deprecate it.

It's notable that tests usually end up running with both hashes enabled, but may be run twice to see fixtures with either SHA-1 or SHA-256 enabled.

Cutting unused dependencies with "the machete"

There is now cargo machete in CI, which was quite necessary now that I don't use RustRover anymore and Zed/RustAnalizer lacks similar features.

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.

Cheers Sebastian

PS: The latest timesheets can be found here (2026).