Do we think of Git commits as diffs, snapshots, or histories?

I think of git commits as both diffs and snapshots. If you see the repo's history as a graph, a commit is a node (snapshot) with an edge to its parent (diff - kinda; also let's ignore merges), which is itself a commit. I think mental models that omit either component are fundamentally flawed and can only accommodate some git operations, which is reflected by the author stating they have to switch mental models.

This is a fairly low-level model (it doesn't match exactly what git it doing but that doesn't matter) that I find it both extremely robust (can't remember the last time it failed to explain something) and yet simple enough that it is my actual working model in day-to-day operations, not merely one I go to when I'm stumped (although to be fair it probably started that way many years ago).

Git uses the node for identification (and metadata, e.g. commit message), and the edge for semantics. Since the node is used for identification, it can't change, but you can have several edges with the same diff which it can be useful to think of as "the same commit".

- `git show COMMIT_ID` finds the node, follows the parent edge, then compute the diff between those two nodes - `git rebase` is creating a new node with a new parent node but the same diff associated to the edge (properly defining "same diff" here is another can of worms) - Changing a commit message is creating a new node with the same parent and the same diff ("modify the node") - Amending (also fixup, squash) is creating a new node with the same parent and a different diff ("modify the edge")

Intuitively I've always view them as diffs with a history rather than sort of a recursive diff. I also started on RCS so that could have something to do with my way of looking at it.

More comments here - https://news.ycombinator.com/item?id=38888527