Merge pull request #1900 from GitoxideLabs/reporting

Report for March 2025

Author: Byron

etc/reports/25-03.md

@@ -0,0 +1,48 @@
+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](https://github.com/EliahKagan) and [Christoph Rüßler](https://github.com/cruessler). 
+Plentiful were also the bug reports, many with started, yet unfinished fixes.
+
+## What's going on?
+
+[GitButler](https://gitbutler.com) 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.
+
+## Community
+
+### Various infrastructure and portability improvements
+
+It is thanks to [Eliah Kagan](https://github.com/EliahKagan) `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 weight
+
+One major source of issue reports now seems to be the fantasic [`jj`](https://github.com/jj-vcs/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 cache
+
+Thanks 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 `helix`
+
+It's fantastic to see that despite `blame` being relatively early in `gitoxide`, it's already deemed good enough to power [inline-blame in `helix`](https://github.com/helix-editor/helix/pull/13133).
+This might be the first third-party integration, and hopefully not the last either.
+
+### Gix in Cargo
+
+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)](https://github.com/Byron/byron/blob/main/timesheets/2025.csv).