[April] A first step towards gix status and .gitattributes matching

[Byron]

When trying to summarise this month the term 'mixed bag' comes to mind. Even though there is the clear goal of making attribute matching work through all layers, there have been plenty of contributions for review, or issues to fix. This leads to less feature development than I'd like, even though every fix or contribution is incredibly valuable by itself as it lets gitoxide gain maturity.

Attribute Matching

There was a PR who celebrated its birthday this year, and it wasn't touched for about that long as well. After .gitignore matching was implemented, priorities changed and I never got around adding .gitattribute matching. Fortunately this changed and it was finally possible to merge it.

It's worth noting that attribute matching gave me a hard time as the existing interfaces that were meant to allow sharing code and logic between both matching types (ignore and attributes) were quite geared towards handling ignore matching. Redesigning and separating these very different concerns was mind-bendy at times, but ultimately led to much better and easier to maintain code.

Further, this time around I paid special attention to handing case-sensitivity correctly, which led to some shortcomings in the ignore matching implementation to be weeded out as well.

Something worth mentioning is how hard it was for me to understand how git is handling attribute matches as there were quite some indirections in order to be efficient. Where git uses raw pointers, of course, gitoxide uses types that copy cheaply to probably be just as fast as git while being perfectly thread-safe.

What's missing the integration of attribute matching into the worktree stack, which is able to load .gitattributes files on demand for the purpose of matching while maximizing their use (or minizing the trashing of loaded attribute files).

Maintenance

It's a policy of mine to fix issues right when they come up and interrupt any work when doing so. This usually causes issues to be fixed within 24h to 48h. The most memorable recent issue was an IO error when trying to create empty trees in fast succession.

As it turned out, the current implementation was very naive as it would let any kind of object creation go through to disk, even if the object already existed. This led to the potential for duplicate loose object files (and issues on Windows). It turns out that git does its best to avoid writing objects by checking for their existence beforehand, and that's exactly what's implemented in gix as well now.

Sometimes it's astonishing how long certain naive implementations managed to survive before finally being found unfit to trigger a fix.

Community

Parallel comparison of index with worktree

Thanks to the contribution of helix maintainer Pascal Kuthe, it's now possible to compute the changes needed to turn an index into a worktree, which is one out of three computations needed to implement gix status. It's just a first version but thanks to near-optimal parallelism it already has the potential for outperforming git.

I can't wait to make it available via gix status to but that possibility to the test.

Zlib-ng - now without the -compat

It took nearly a year to mature but finally it became possible to use zlib-ng without the compatibility layer, while also making it more suitable for compilation on a greater variety of build environments. Thank you, Josh Triplett, for the initiative!

32bit support

Thanks to starship gitoxide reaches new frontiers, and now compiles and works on 32 bit planets platforms as well. Thanks again, David, for your continued contributions.

gix-archive - ready for implementation

Thanks to Svetlin's continued efforts we have understood git archive in enough detail to be able to implement an MVP of it. To me, its main benefit is that it will require using code that is also used for checking out worktrees, and that alone will make it cleaner and more versatile instead of being 'overfitted' to a single use-case. It doesn't have to be long until gix archive can produce the first tar-streams.

Rust Foundation sponsorship: cargo shallow clones update

Due to a blocking in cargo itself there wasn't much movement for the majority of the month. But with that resolved, the review could go into the last round and is now in the final comment period. When merged, shallow clones are possible both for the index and for git dependencies 🎉.

Cheers,
Sebastian

PS: The latest timesheets can be found here.