Add monthly report for January 2025

Author: Byron

etc/reports/25-01.md

@@ -0,0 +1,60 @@
+Welcome back to the first month of 2025!
+The year definitely starts off well with a complete implementation of no other than… `gix status`.
+
+## `gix status`
+
+For a while now there was `gix status`, but it was unable to see changes between `HEAD^{tree}` and the current index.
+This was now [rectified](https://github.com/GitoxideLabs/gitoxide/pull/1410) and `gix status` can serve as early demonstration of the newfound powers.
+
+A notable limitation is that sparse repositories aren't yet supported, even though it probably won't take too much to get that done, just because there weren't enough famous last words in these reports yet.
+And finally, besides performing favorably compared to `git status`, performance [seems to be inconsistent](https://github.com/GitoxideLabs/gitoxide/issues/1771) on other platforms.
+
+This will require more investigation and I can't wait to see it fixed, as overall having an even faster `git status` implementation is a big deal for a lot of tooling.
+
+## Upstream and Remote
+
+Given a tracking branch name, like `refs/remotes/origin/feature`, the new method called [`Repository:: upstream_branch_and_remote_for_tracking_branch()`](https://github.com/GitoxideLabs/gitoxide/pull/1763) will find the name of its upstream branch along with the matching remote. It is as unwieldy as it is powerful, as performing this feat isn't quite as easy splitting some strings on a slash and recombining them to match the names that will work 99% of the time.
+
+To capture the remaining 1% of correctness one will have to reverse-map the refspecs of all remotes to obtain the upstream branch from the local tracking branch (which served as input). If the result is unambiguous, a match means we have found the remote as well.
+
+## Various improvements
+
+Besides some features, I felt that considerable time was spent on bugfixes as well.
+
+### Better ObjectDatabase failures
+
+The title sounds like there should be no failures at all, instead of having 'better' ones, but please hear me out :D, it's an issue initially discovered in [rust-crates-index](https://github.com/frewsxcv/rust-crates-index/issues/181).
+
+When fetching from a remote, a pack will be written if it's not empty (which is a corner case, but not the norm). Additionally, the refs will have to be updated which will check for the existence of the tips of the commits that were sent. And that, that will force the new pack to be loaded.
+
+It's probably already clear what the problem is, but… it is *not* that the process runs into file descriptor limits, at least not yet. Before that, `gitoxide` object database runs into the limited amount of files it can manage as internally as it uses a fixed-length slotmap.
+
+By default, the object database starts up with twice as many slots as it would need to fully load the repository, or at least 32.
+Previously, when these slots were exhausted, it would actually go into an invalid internal state and at best simply not find the new objects, and at the worst panic.
+
+That invalid state of course was never intended, and now it will correctly return an error that clearly states it's out of slots.
+It's still, however, hard to recover from it right after a fetch and one would probably have to repeat said fetch even though one probably wouldn't receive the pack again.
+
+
+### Submodules with Worktrees
+
+https://github.com/GitoxideLabs/gitoxide/pull/1762
+
+## A security vulnerability with 'too many bits'
+
+https://github.com/GitoxideLabs/gitoxide/security/advisories/GHSA-fqmf-w4xh-33rh
+
+## Community
+
+### Experimental support for `gix blame`!
+
+https://github.com/GitoxideLabs/gitoxide/pull/1453
+
+### Starship with light-speed!
+
+https://github.com/starship/starship/pull/6476
+
+Cheers  
+Sebastian
+
+PS: The latest timesheets can be found [here (2024)](https://github.com/Byron/byron/blob/main/timesheets/2024.csv).