> Obviously both "diffs" and "snapshots" are leaky abstractions..... Joel Spolsky wrote many great things, but "all abstractions leak" was not one of them (edi

> Obviously both "diffs" and "snapshots" are leaky abstractions..... Joel Spolsky wrote many great things, but "all abstractions leak" was not one of them (edit his but not good). I am very tired of programmers excusing their poor imagination with appeals to this nonsense. ------ Commits store snapshots. Full stop. The "bad mental model" is not commits being snapshots, but things behind stored individually, i.e. > Sum |things| = |Product things| This comes up in many other contexts, especially when storage quotas are involved and it's unclear what to do when storage is deduped across quotas. ----- git packfiles do use a delta encoding, but it's important to understand that there isn't any necessarily any correspondence between the history and the delta encodidng. In fact, commands like `git repack` exist precisely to avoid path dependency issues from the repacks matching the history too much. Saying commits are diffs to explain the delta-encoding storage characteristics is wrong and confuses, not clarifies. ------ > And let's not forget commit messages. If a commit is a snapshot, I would expect the commit-message to be descriptive of the entire snapshot. Whereas if a commit is a diff, I would expect the commit message to be descriptive of the diff. Which is exactly how most people use commit messages. It's git tree objects that are snapshots, commit objects have tree child and a prev commit child, so it is natural for them to describe the relationship between two states without appealing to hypothetical alternatives. > Not to mention other features the article discussed, such as cherry-picking. What does it even mean to "cherry-pick a snapshot"? In comparison, cherry-picking a diff and applying it to your current state, is far more intuitive. I might `git checkout somethingelse .` mid-rebase. What does that mean if commits are diffs? Nothing very clear. The better thing to teach people is about darcs and patch theory and those other modules. I think the git model and the patch theory model both have uses, and the fact that git makes people always work in the git model is a fundamental issue that cannot be fixed with analogies. - Patch theory is good for the things are you still working on - merkle dag of states is good for the things you've already done / agreed upon.