etc/reports/25-03.md
Very much like in the past month, this month once again has nothing I could proudly share, at least not based on my own work. Fortunately, there were lots of contributions, particularly by Eliah Kagan and Christoph Rüßler. Plentiful were also the bug reports, many with started, yet unfinished fixes.
GitButler is still taking most of every day, then there were 7 days of basically not using the computer (something my inbox still is a proof of nearly two weeks later), single-dad trials keep me busy with childcare once kindergarden is out, and then there is dealing with everything that needs to be cared for in Germany while I am in China. Simple as that 😁.
On the bright side, I of course also enjoy getting to work significantly less, getting a taste of a normal 9-5 working day, something that's going to be over soon enough as I do plan to take it into the other direction as soon as I get the chance. In theory, from mid of April I should be able to ramp up my worktime again, even though it's still unclear how much of that can go into gitoxide features, or into all the half-finished PRs I have currently open.
I will do my best to work it all off to even be in a state to think about new features, with candidates being a git2-style commit-walk and a proper gix reset.
Part of me thinks that in theory, even when working significantly more, it's likely that there will be ore months without anything significant to share, a state that might not change until the next major iteration GitButler see the light of the day and has all the features. Only then I'd think it will be possible to make the improvements that gitoxide needs to be able to fully remove git2 there, the final boss if you will.
It is thanks to Eliah Kagan gitoxide is tested on more and more platforms, while also running better on the Windows platform. Anything related to CI infrastructure and developer tooling by now has been thoroughly revised, and I am happily taking the back-seat to enjoy the ride.
A notable workstream that was also concluded recently is a greatly improved algorithm to find the correct Git shell on Windows - what sounds trivial is full of gotchas and required a huge amount of testing to get it to the point where it arguably is the most portable and compatible implementation.
jj puts in its weightOne major source of issue reports now seems to be the fantasic jj, a tool I always abbreviate because I can't remember how to spell jujitsu (this is probably wrong).
It's made by Google, and it really is great to see its influence on gitoxide - each report leads to betterment, and I can't have enough of that.
On another note, I am a great fan of the look & feel of the jj codebase, and kind of wish gitoxide could be like that.
For fun, let me finish with a confession: despite having seen intriguing demos, talks, screen-recordings and documentation I still didn't dare to simply try it out. And all that despite thinking that it could make a huge difference for my workflow. It's the "I can't really have a disturbance in my workflow right now" phenomenon, but I keep hoping I will one day find myself in the right mood to just give it a go.
gix blame with experimental cacheThanks to Christoph we now have gix diff file to use, producing unified diff of anything currently stored in Git. And I hope that future upgrades will enable it to also be able to read from the worktree, making it a driver of the gix::diff:blob::Platform, effectively.
In other news…
gix-blame will be used in helixIt's fantastic to see that despite blame being relatively early in gitoxide, it's already deemed good enough to power inline-blame in helix.
This might be the first third-party integration, and hopefully not the last either.
With gix status now available, the plan still stands to bring it into cargo. Before that, there is a huge stack of unfinished PRs to wrap up though, so it's unlikely to happen anytime soon.
Cheers Sebastian
PS: The latest timesheets can be found here (2025).