Since we last spoke …
Here in the United States, we are celebrating our Thanksgiving holiday today. Among the many things I have to be thankful for, one is the opportunity to spend time deeply learning git through building the Xgit library.
Some other aspects of my life have required extra attention in the last month or two, so progress on Xgit has slowed but it has definitely not stopped.
There have been three new releases in October and November. As usual, each release focuses around one “plumbing”-level API:
Xgit.Plumbing.CatFile.Commit. This is an API equivalent to
git cat-file -pwhen the target object is a
commitobject. This was marked API breaking because some implementation details were marked private.
Xgit.Plumbing.UpdateRef. This is an API equivalent to
git update-ref. This was marked API breaking because the behaviour contract for
Xgit.Repositorywas extended to add reference-related operations.
GitHub Universe and GitHub Actions
I had the honor of attending the GitHub Universe conference a couple of weeks ago. It was great to see the vibrancy of Git and GitHub and to have a chance to meet with people building and supporting this ecosystem.
If there was one takeaway from this conference, it was that GitHub Actions are the new hotness. (Yes, similar things have existed elsewhere for some time, but GitHub has the market- and mind-share these days.)
While at the conference, I retooled Xgit to use GitHub Actions as its primary build system. This prompted a change to using CodeCov instead of Coveralls, as the Coveralls API is not well-suited to receiving data from GitHub Actions builds as of yet.
I’m finding the new build system substantially faster (thank you GitHub Cache Action, among other things) and more reliable than the previous system. So far, I’m quite happy with the new system.
A Tribute to Noms
I was recently introduced to Noms, which describes itself as …
… a decentralized database philosophically descendant from the Git version control system.
I’m sad to read that “nobody is working on this right now” since Noms appears to have been instigated for many of the same reasons that inspired Xgit.
We align on:
- Supporting offline-first applications (or, as I’ve seen recently, local-first applications).
- Being versioned and auditable.
- Allowing synchronization in arbitrary patterns (i.e. peer-to-peer in addition to cloud-to-client).
- Allowing for extensible storage mechanisms (S3, etc.).
We differ on:
- Technology choices (Go vs Elixir).
- Whether we use git directly (Xgit) or are influenced by it (Noms). (Xgit provides a server-focused implementation of git and assumes client developers can use
jgit, as appropriate for the platform at hand.)
- Whether we provide structured-data support intrinsically (Noms) or not (Xgit). In Xgit, I consider this to be a separate, but closely related problem. I prefer to allow application developers to layer on their own structured-data and conflict-resolution mechanisms.
Regardless of which libraries thrive and which ones fall by the wayside, I hope the concepts explored by Xgit and Noms live on.
There are a few more reference-related operations and concepts to implement: