Merge pull request #2181 from GitoxideLabs/report

Add monthly report for September 2025

Author: Byron

etc/reports/25-09.md

@@ -0,0 +1,53 @@
+By this time I think it's fair to say that I am mostly busy with GitButler, and `gitoxide` doesn't receive more than basic maintenance and the occasional fix.
+Fortunately, this isn't at all bad news as GitButler uses `gitoxide` and will only use more of it - it's just that for now, getting what's there stable and safe
+is more important.
+
+## GitButler - Apply & Unapply
+
+These are fundamental operations for GitButler as they add and remove a branch from the GitButler workspace. After the core-engine was rewritten, this operation is more flexible than before and that, in turn, costs time to fully test and implement. And of course, all that has to happen in a way that is compatible with all the 'old' code that is still doing a lot of the heavy lifting, so workspaces have to remain compatible for now.
+
+In the process of dealing with this, a new primitive was created: 'safe-checkout'. As such, it's a checkout that is very similar to what Git does when checking things out, except that it's willing to merge locally changed files as long as there is no conflict. The actual checkout is still performed by `git2`, but that's quite slow and lacks compatibility with Git to the point where `git-lfs` is not supported.
+
+Thus, a way to *reset the working tree* to a known state *after* the caller did their own due-diligence is a feature that is planned next to make 'safe-checkout' faster and better. For `gitoxide` this doesn't even mean too much as all the primitives to do this safely already exist - they merely need to be recombined. If everything goes well, this would mean that rather large checkouts that cost 16s with `git2` and 11s with Git could take as little as 2.2s with `gitoxide` with as little as 3 threads.
+
+And that, in turn, would make real difference for developer tooling.
+
+## Community
+
+### `gix::Repository::blame_file()`
+
+Thanks to [Christoph Rüßler](https://github.com/cruessler) `gitoxide` had a very competitive `gix blame <file>` implementation for a while already, and one that was available on the command-line as well.
+
+Now, however, he also added it to the `gix::Repository`, making it available other tools with ease - previously they would have to use the plumbing in the `gix-blame` crate directly.
+
+It's notable that biggest shortcoming is still "The Slider Problem" stemming from us not using the same `xdiff` implementation that Git and `git2` use, but… it's already on how list of problems to tackle. Stay tuned.
+
+### Zlib-rs is now the default
+
+By the hands of no other than [Folkert de Vries](https://github.com/folkertdev) `gitoxide` could completely shed its dependency to `flate2` along with all the feature flags to select from its various backends, and replace it with direct access to the `zlib-rs` C-API to eliminate that abstraction layer entirely.
+
+And as it's planned to make `zlib-rs` expose a pure-Rust API as well, I am sure `gitoxide` is on the list of projects to try it out with as well.
+
+### Better Git installation detection on Windows
+
+On Windows, and thanks to the unmatched attention to detail of [Eliah Kagan](https://github.com/EliahKagan), `gitoxide` will now be able to detect Git installations even if these are per user.
+
+And having that is still quite crucial for tooling to do the best possible job, just because many hooks rely on tooling that is only available in the Git-provided Bash shell. After all, Git ships a small Linux environment along with it nowadays.
+
+### The advent of AI Part 2
+
+> `gitoxide` is feeling the impact of AI tooling, such as agents and IDE integrations that allow for the generation of copious amounts of code. 
+> The adequate response is still unclear to me, and I have tried auto-reviewing with Copilot and even proactively launching Copilot to attempt resolving entire issues itself (-> it doesn't work).
+
+This was written last month, and this month I may add that Copilot is a hammer I find useful. It's made for people like me who don't like to *actually* work with AI and let it write code as it turns "thinking + writing" into mostly "reading + trying to keep up". What it allows to do is to one-shot a solution or *a basis for a solution* with minimal effort. And even though often this produces garbage, I have celebrated many successes with it as well leading to fixes and improvements that wouldn't (yet) exist without it.
+
+It's viable, and it's valuable, and I am curious if it gets more powerful or if it will remain in its niche.
+
+### Gix in Cargo
+
+There is good things on the horizon. 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)](https://github.com/Byron/byron/blob/main/timesheets/2025.csv).