Gitoxide

[jpgrayson]

I've pushed a patch that replaces git2 (libgit2) with gitoxide (054edb2).

I've been keeping an eye on the gitoxide project for a while now and in recent months its capabilities grew and improved to where I thought it might be possible to replace StGit's use of git2. In the last several weeks since the StGit 2.1 release, I worked on a patch series that attempted to make this switch.

The result: it worked out great.

Gitoxide's capabilities are at parity with the subset of git2 that StGit uses, which is to say that gitoxide provides a sufficient abstraction over a git repository (via its git-repository crate) for object database and reference lookups/modifications as well as access to git configuration.

Most of the changes necessary amounted to spelling things the gitoxide way instead of the git2 way, with just a few places where gitoxide improved things over git2 (e.g. signatures) and a couple places where git2 capabilities had to be replaced (finding merge bases and message prettification).

The most immediate and concrete win from switching to gitoxide is that StGit command overhead is reduced by about 10ms. The various stack interrogation commands such as stg series and stg top went from taking about 12ms down to about 2ms. This has a big impact on the test suite, which now runs in about 3s in my environment. I must say that the test time reductions from the Python -> Rust(git2) -> Rust(gitoxide) migrations have greatly increased my velocity and confidence in making changes to StGit.

Other wins for gitoxide that I anticipate include:

• Easier upstream contributions. Gitoxide is under rapid and sustained development. It is all written in Rust, including its transient dependencies. And my initial upstream contributions have been graciously accepted. Contrast to git2-rs and libgit2 which requires contributions to core libgit2 in C, and then only after a libgit2 release, corresponding changes to git2-rs. Not insurmountable, but two projects, two languages, and a significantly different timeline compared to gitoxide.
• Richer API. The API provided by git2 is somewhat limited since it is a wrapper around libgit2. Gitoxide can and does expose a more "rusty" interface.
• Broader scope. Gitoxide has ambitions to be able to do more or less whatever git can do whereas libgit2 seems to have more limited goals of supporting a subset of git needed for some key server applications (i.e. GitHub). The hope is that gitoxide will thus eventually be able to replace some/many/all? of StGit's uses of git subprocesses.

It is now time to dog-food StGit built with gitoxide. The test suite passes, obviously, but I need to get more real-world shake-out before this change makes it into a StGit release. I'd love for brave StGit users to provide feedback.

Thanks!

And especially thanks to @Byron for the gitoxide project.

[Byron]

This post is the first one I am reading in the new year, and I am thanking you for making it such a positive and rewarding one 🙏❤️.

I am particularly (and positively) surprised by the time saving that gitoxide provides and it's good to see that being mindful about performance in every plumbing crate is inherited so neatly into git-repository to bring it all together.

Broader scope. Gitoxide has ambitions to be able to do more or less whatever git can do […]

Yes, but… the roadmap is driven by supporting most typical uses of git2 to allow its replacement for 95% of its uses and then move on to get a git server ready. Thus I don't see myself implementing something like rebase anytime soon, but believe that especially by then the plumbing exists to conveniently implement it. So I am hopeful that the growing community will be able to make such contributions one day.

And now, let the dog-food-feast begin :).