Skip to content

Report for March 2025 #1900

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 22, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 48 additions & 0 deletions etc/reports/25-03.md
Original file line number Diff line number Diff line change
@@ -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).
Loading