1. 14
    1. 1

      It’s worth noting that the post seems to describe “lightweight” tags:

      Tags are like commits, but instead of pointing to a tree and parent they point to a commit, and you can move them later (as opposed to everything else we’ve seen so far, which is immutable.)

      These tags are refs rather than Git objects (although that doesn’t mean that they’re not worth modeling). “Annotated tags” are the fourth and last kind of Git object, and are immutable. They point to a commit and contain a message. It’s perhaps worth modeling them, but there’s limited pedagogical value since the post already discussed the well-formedness of the object graph (such as avoiding structures like objects containing themselves through cycles).

      Let’s look at the instances Alloy produces and see if we think any of that feels off

      It’s frustrating that there’s no better way to do this, since there is no specification for a well-formed Git object graph. As far as I know, the spec is “try it with git fsck and see if it works” 😂.

      We’ll just update our definition of Tree to say that they can’t have commits as children.

      I think Git actually does allow commits as children of trees in order to implement submodules, but you have to mark the file mode as a gitlink (mode 160000 rather than 160644). Note that gitlinks do not keep the pointed-to commits live in the object graph (indeed, the user may not even have access to the submodule repository to begin with).