The original workflow, which is still in use today, is git-blame followed by git-show: look up candidate commits, then examine their history individually. This can be accelerated with a GUI; e.g. GitHub and GitLab support blame-style views.

I agree that the UX of existing git commands is not great. They evolved in a particular insular environment – Linux kernel development with heavy mailing-list usage and large multi-headed merges, with occasional pull requests and manual integration testing.

Check out my top-level comment for a link to git’s data model. A data-first approach with blob, tree, commit, and tag can be enlightening. The on-disk format tries to balance integrity, easy manipulation, disk space, and incremental updates; it’s also weakly monoidal, enabling distributed development. Look up the history of Bitkeeper and git; this is “a version control system [designed] from the ground up with documented architecture from the start”! And there are many non-C implementations as a result, like pure-Python dulwich.

A PDF is available here, and analysis from Colyer 2016 is good.

This paper is fascinating in terms of ethnography. Consider: the paper mentions “branch” or “branches” dozens of times, but only says “tree” four times, and every instance is in the phrase “working tree”. The paper never mentions “blob” or “blobs”, “DAG” or “graph” or “poset”. The authors either chose to omit git’s data model, or they don’t know about it. The implication is that the UX and UI don’t reflect the data model, I suppose, but it is a very curious omission.

Now, contrast this with Git’s documentation. When sysadmins teach git, we focus on the data first. git is a kind of database which stores four different flavors of object, and the git UI is merely a collection of commands for programmatically manipulating the database. All of the various UX is purpose-built, on a per-command basis, for development workflows. New commands can be implemented as plain UINX-style executable scripts in any language.

In summary, this paper looks at git as a version-control product, while its developers and users look at git as a version-control framework.

There was a followup paper from a few years later, also with Colyer 2016 analysis; this paper has too many glaring defects to discuss here.

On a personal note, I saw this and am happy to note that science has marched along:

We plan to extend our notation to make it more expressive in the future, but are cognizant of the fact that diagrammatic syntaxes for first order logic have a long and troubled history.

Not long after this paper, ontology logs were figured out, which can be made as expressive as needed for the case of relations; see Patterson 2017.

I’ve put ASTs directly into git repositories by encoding each leaf as a blob and each tree as a tree. Since git objects are content-addressed, this gives deduplication of ASTs for free, including CSE for sufficiently-pure ASTs.