[August 26] - gix-notes!

[Sebastian Thiel (Byron)]

This month certainly feels like great progress, with 48 community PRs merged and a lot of notable improvements. It's also no surprise to see such numbers: everyone seems to have accelerated, and I am keeping up only by crunching from morning till night. But it's also an incredibly exciting time, and I couldn't be more motivated to do it.

I myself have also been busy continuing the great cleanup and making certain improvements before I continue with feature work. Some features snuck in nonetheless…

Git notes!

I had probably already been a Git user for 10 years when I finally discovered Git notes, and I found them incredibly intriguing. How cool is it to attach arbitrary metadata to any Git object? Imagine the cool things one could build with that - code review, issue tracking, metadata in general!

And now, another couple of years later, it's safe to say that none of this has materialised and that it's more of a niche feature.

But tix motivated me to make good use of it, so here we are with gix::Repository::notes() for querying and editing. tix uses it for per-worktree metadata such as a to-do tag and general notes, as well as a 'qa-pass' marker for trees, which naturally goes away if the tree changes again, indicating that QA has to be redone.

All in all, it's super-useful for building custom tools to support your workflow, and I certainly have every reason to use Git notes more in the future.

Signing and verification of commits and tags

My work on tix motivated me to finally tackle signature verification and signing itself, and OpenPGP, X.509, and SSH are all supported and tested. In that process, gix-testtools also got a bunch of signing-related primitives to facilitate this kind of testing everywhere.

TIX!

The tix CLI has been making great strides, and it is already my daily driver. It now supports edits with automatic rebasing, a new way to handle conflicts, and even sports a special "review" tool that I use to review all contributions.

That review tool simply automates a previously cumbersome process:

• create a new commit at the base of what's to be reviewed
• check out the worktree at the topmost commit to review (so one can review multiple commits at once)
• re-add each hunk to the index and make changes at will during refactoring
• once the worktree is clean and the commit contains all changes + refactorings, put this review commit on top of the topmost commit of the stack under review

The last step, which finishes the review, is notably not a cherry-pick, as that would cause conflicts. Instead, tix simply adopts the exact tree from the review commit, which naturally exposes my changes.

Despite the usual hassle of fully generated tooling, such as degeneration and old issues popping up again, the overall trajectory is towards "it's getting better". It's also a delight to see that it's possible to create such tooling at all.

In any case, tix is already an incredible help in learning which concepts work and which don't, so gg can start with the right ideas and concepts from the get-go.

And before I go: one of the hardest parts of this gen-only workflow is keeping up with your own creation. Often, I create features that then won't actually be run for quite a while because I am already doing other things. So in the end, it does feel more like a skill to master than anything else, and… lots of mistakes are part of the process.

The version I am describing hasn't been merged yet, as some necessary changes to gix-* crates haven't finished their reviews, so gix tix is still only at its first, very early release.

A fully functional fetch implementation!

For the longest time, the delta-resolution algorithm had two major problems, one a deal-breaker and the other merely problematic:

1. thin packs with in-pack objects couldn't be handled
2. parallelism didn't work well for imbalanced delta trees, and it consumed too much memory

Problem 1 meant that fetches didn't work at all for Azure DevOps-hosted repositories, and some GitHub repos had the same problem. It was a bit hit-or-miss and a complete deal-breaker. Now, the algorithm can schedule deltas for resolution once it has seen their bases, and the rest is just business as usual.

Problem 2 could mean that repositories like phpstan would take multiple times longer than Git and use a lot of memory. crossbeam-deque is the key to work stealing, solving the performance problem, while a better way of handling buffers (and their lifetimes) leads to optimal performance in both speed and memory consumption.

All in all, the change amounted to just a couple of hundred lines of code, and a mild refactor on top made everything so much cleaner. Admittedly, this wouldn't have happened without an agent, and I definitely learned some new tricks during the lengthy refactoring and review process.

Greater Robustness

Both fuzzers and LLMs keep probing the codebase and finding issues, which are typically fixed the same day.

One I particularly want to highlight is #2921, which fixes what feels like a day-one bug: when a held lock triggered a specific error, trying to collect error information would cause an infinite loop. The fix was trivial: actually update the cursor while walking a chain (while let Some(cursor) { ... cursor is never updated here ... } was the problem).

• #2867 hardened URL authority and path parsing for a draft high-severity advisory.
• #2869 validates delta base sizes.
• #2918 rejects overflowing cache-tree entry counts found by OSS-Fuzz.

Greater tree-merging conformity with merge-ORT

Clearly, this is another great use for LLMs: increasing code coverage and writing baseline, cartesian, and fuzz tests to trigger many more issues in the current code and then fix them.
Benchmarks are easy to generate as well, and the primary use case is to protect performance across changes.

This is what happened to gix-merge, which now conforms to merge-ORT much more closely than ever before. Remembering how time-consuming this work was when I did it back in the day, LLMs truly are a godsend.

No Git3/Reftable progress

Somehow, I am stuck refurbishing and fixing what has long bothered me, knowing that it will make the implementation of what's to come easier on the eyes and improve the quality for everyone while the big features are in progress.

Community

As you can imagine, most contributions are now heavily LLM-assisted or fully generated - it's often unclear which - and most of the time it feels like I am talking to bots. Over time, I hope the distinction between human and generated speech will become clear. But besides that, these are really just contributions like any others, and they get exactly the same treatment. I appreciate that most of them truly are fixes or improvements that make gitoxide better for everyone.

I will cut it short here in the interest of time. With so many contributions, it's hard to single anyone out, except perhaps for a shout-out to Christoph Rüßler, who keeps chipping away at big topics and patiently bears the many words I send his way during our contributor lunches and breakfasts :D.

Gix in Cargo

There is nothing new here, but let's keep the horizon active:

With GitButler slated to have its checkout driven by a tailor-made implementation of reset in gitoxide, this is coincidentally exactly what Cargo would need to greatly speed up its checkouts and make them more compatible with Git, too. We are talking about proper Git filter support and speedups in the realm of ~7x.

Cheers,
Sebastian

PS: The latest timesheets can be found here (2026).