[July 26] - Meet Tix!

[Sebastian Thiel (Byron)]

Byron is back! And I have a plan! A plan to finally bring it all together.

• Clean up gitoxide issues and PRs and keep them clean. Issues are now something
  to work on in the near or medium term at most, not a dump of information to get back to later.
  The reasoning here is that knowledge is now instant, and if issues become a weight on my mind,
  they aren't useful. Instead of issues, PRs can be created instantly as well.
• Get Git3 ready with Reftables.
• Work towards gix 1.0, not for feature-completeness, but for API stability.
• Get Python bindings!
• Use them as an optional backend for GitPython, which is downloaded a mere 260 million times per month.

Let's see how much of that can be done by the end of the year, with Git3 being mandatory
until the deadline.

gix tix :D

As part of my agent experimentation, and to close an issue, I wanted to try something new: Is there a place where unreviewed agent code can exist?

My answer was: Yes, in gix (CLI), where everything serves gitoxide developer support. Everything is possible, and if it's functionally OK and reasonably safe (i.e. read-only), there is no reason not to try something fully agent-generated.

And so it only took a few prompts to go from tig to tix, which is the tig I always wanted.

You can try it with gix tix, or cargo install gix-tix for the standalone tix binary.

Highlights include about 40% less similar memory consumption with larger repositories (e.g. the Linux kernel), and a 15× speedup over tig on the same repository (8.5 seconds until fully ready, while being immediately usable, vs 2 minutes until fully ready).

Please also note that the commits mark GPT as the author, without me as a reviewer. There are some confusing earlier commits unrelated to tix which also have GPT as the author, but me as the reviewer, which indicates a diligent refactor and review. Nowadays, I take authorship of agent-created commits, as it felt too odd not to be visible in tix anymore.

gix-config quasi 1.0

gix-config has seen a push of improvements that I had planned for a long time and could finally act on thanks to agents.

Did you know that gix-config was fully contributed? And that I had different plans for its architecture? And finally, that I committed some API blunders that made its use extra inconvenient downstream?

Well, all that is fixed now, and in the process, it uses less memory and is about 30% faster during parsing. And downstream users will find it much more convenient to use.

This makes it quite a breaking change, but it's for the better, and agents will have an easy time making the necessary changes as well.

Better object database

Besides another security fix that should make it harder for packs to trigger large allocations, particularly when the pack is untrusted and the 4GB memory limit is enabled, the loose.compression, core.compression and pack.compression configurations are now respected.

This also contains a fix where zlib-rs's default compression is set to match what Git would produce, as after the switch our compression was noticeably worse due to differences in default values.

Error handling is better too, in the sense that underlying zlib errors are now preserved, which can help with understanding the nature of object read failures.

And finally, there was the possibility of panics due to reaching formerly unreachable code… turns out it's quite reachable when there are multiple handles to the ODB, and one triggers a re-read of the packs or indices with changes to the slotmap, while the other handle still refers to a now-unloaded one. The solution was just to… not panic, and let it take its natural update route, so it can try to find the object again with a recent view of the loaded packs and indices.

gix-error - what's up?

The plan was and still is to get rid of thiserror, primarily to avoid pulling in syn and the like for faster compile times, but also because it's now easy to write error types by hand. And now that a concept for stability has materialised, it has become clear that it's actually OK to keep custom error types as enums for precision, at least in plumbing which never has to be stable.

Then in gix, these will be brought into gix::Error, which has to learn to perform basic analysis of the error chain to help with questions like "can this be retried?" or "is this an environment error?", i.e. was the network interrupted?

A lot of work is currently ongoing, and I am evaluating if such a large-scale refactoring can ship in a single PR. Reviewing 10k lines of code will take… at least a few days, but what's done is done, right?

Everything else

Checkout robustness

Previously one could define an unknown worktree encoding via .gitattributes, and that could make a checkout fail as the encoding wasn't found. Now, this is only logged by default (with an option to fail instead), so the checkout can proceed just like it does with Git.

When checking out and filters are involved, executable bits will now be set and unset correctly.

Finally, on Windows, symlinks could be followed during checkout under certain circumstances because the Windows implementation lacked the NO_FOLLOW protection that Unix has. This is now fixed, and is a good reminder of how hard this is to get right, with more well-hidden traps than one can count.

Stable rename tracking

The results of rename tracking previously could fluctuate as they were dependent on… hashes. I know, it's silly, but it happened, and now the order of inputs is stable. It's notable that rename tracking is still based on my own 'creation', which gets it close to Git, but ultimately remains far inferior when it comes to all those edge cases that we run into once or twice per day/week/month. It should definitely get another makeover, but this can probably wait until it's a real/noticeable problem.

HTTP authentication fix

When HTTP gets redirected to another URL, gix would previously reject the redirect to avoid sending credentials to a new host. This is fine, but Git handles this better by simply re-authenticating against the new URL. This is what we do now as well, and ultimately it fits well into the current flow which is mostly implemented in gix itself. Maybe one day this can be abstracted into smaller building blocks to give API users more control.

Community

Faster gix status on Windows!

Thanks to the relentless optimisation work of Special Bread, gix status is now much faster on Windows. While there is more to come, here is how this one optimisation works.

The Windows-only core.fscache configuration is now supported, which brings Windows performance much closer to Linux, which is blessed with fast lstat calls out of the box. It works by not doing a bare stat, but instead using a cache for the stat result. This cache will lazily read the parent directory and list all entries, with the listing including stat information automatically.

And while I thought that this should be good on Linux too, it isn't because there is no API for that. Fair enough, lstat is already fast there.

The world's first (?) Git configuration formatter

Thanks to Amey Pawar, there now is gix config fmt, a trivially implemented lossless formatter which can rewrite configuration files based on what Git would write if they were created with git config. It's pretty nifty, even though I probably won't be using it given that I never felt the need. Maybe that's also the reason that this might be the first formatter of its kind.

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 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 realm of ~7x.

Cheers
Sebastian

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