There have been plenty of noteworthy contributions this month, let’s dive right in.

GitButler

As I am mostly busy with GitButler, it’s fair to share a little bit of my work here. It’s very relevant for gitoxide as GitButler now drives its features, and getting to a good state there means I can spend more time on gitoxide again.

With the arrival of the but CLI program, there now is an official way to use GitButler without the user-interface. It also allows us to iterate much faster, and most importantly, have the very first ‘modern’ version of GitButler earlier as there is no baggage. This mainly means that GitButler can operate on any branch, not just gitbutler/workspace, among other things.

And to enable that, I have been very busy to partition the codebase further and set it up to support that first ‘modern’ version of the but binary, which came with a huge refactor that may well have solved the last remaining problem between the server, the tauri-frontend and the binary, weaving them all together.

Now I hope to soon be able to show examples for a modern but status and but branch apply implementation so more can follow, along with marking existing implementations as ‘legacy’ to indicate they still use old APIs and need to be ported over.

AI Stuff: If you can’t defeat it, embrace it?

Having made quite a journey, from wanting to defend against actual AI slop to using AI myself for one-shot solutions to small and ever-growing problems, one thing seems clear: it’s getting better, it’s getting more usable, and it delivers real value.

For that reason I added Copilot instructions to the project which are a great read even for human developers who want more details than DEVELOPMENT.md. And from what I can tell, I really should use it even more and try to occasionally fire of fix-attempts for real issues. All I have to do is review and refactor them, which makes the workflow very similar to other contributions with a comparable quality as well.

Community

500x Faster Theseus Plots with “Gix of Theseus”

This post may very well be the surprise of the year for me, as we are looking at a standalone incremental blame implementation that uses gitoxide primitives to build an incredibly competitive rayon-based multithreaded implementation of gix blame.

It is my hope that this knowledge can influence the gix-blame crate positively, to one day deliver a best-in-class blame implementations for the CLIs, TUIs and GUIs of this world.

gix-transport and gix-protocol cleanup.

These crates have suffered from a non-standard implementation of async and blocking code as the respective features were non-additive, as every Cargo feature ought to be. And thus far, I couldn’t make myself clean that up as I remember the pain building it.

Fortunately, Dirkjan Ochtman didn’t have this issue and got started on the topic, delivering one PR after the other to clean this up. And even though it’s not fully done yet, at least the plumbing is in a much better state than it was before.

Thanks so much!

gix blame diff-slider tests

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. But fret not, thanks to Christoph Rüßler we now have a generator for tests that compares our implementation with the baseline produced by Git.

This will enable us to implement diff-slider adjustments ourselves, or by inheriting them from imara-diff v0.2, which has the implementation but not the tests.

We will get there :).

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).