It's technically correct. The key thing here is that it's isomorphic. You can either have a system of commits in which diffs are computed between commits or a system of diffs in which commits are computed by applying diffs. The trade-offs are in performance of various operations, not in the user exposed semantics. Git chooses to have its first class object be commits and diffs are computed on the fly. So again it's technically correct, but in practice commands like cherry-pick, which treats a commit like a diff between that commit and its parent really blur the line. I think in reality you can be a really advanced git user and not even realize that there's a difference between a commit based and diff base version control system, because in practice there really isn't much of a difference.

Yes,-ish. However, there's also the question of what operations are efficient. (Diff feels very performant in git but) maybe having the diffs as the first-class objects enables doing something efficiently that git doesn't do. (perhaps, identifying when identical patches have occurred in different portions of the history?)

I've used several patch-based VCs (RCS and CVS) but I think they pre-date this "sound theory of patches" and instead the use of patch-style representation was for optimizing storage. (just as git uses packs and deltas to optimize storage and performance, f'rinstance) So I don't really know what I'm missing.

(If the sound theory of patches would let me better understand what occurred at a merge commit than git's tooling, that'd be just about enough to sell me on switching. except for the network effects of git & github.)

Consider a small commit with spelling error. If I turn this into a patch and apply it to another branch it will be a different commit even it will be the same patch.

As such, the concept of a "commit" in Git refers to a complete state of everything; a snapshot.

If you inspect the files in the .git directory, you’ll find commits stored as trees of directory and file objects. But it is true that they can be converted diffs on the fly, which is exactly what the git show command does.

> aren’t commits isomorphic to diffs?

Nearly, though renames are only approximately extracted from the snapshots.

That's true, but git doesn't natively have a way to refer to a single diff. You can use a hash to refer to a commit, but that depends on the entire history up to that point. If you rebase a commit then the hash changes, even if the new commit is semantically the same.