Good point to mention! I need to be more clear when I say things like that. For most people the mental model of git is diffs, since that's what we work with as users when we make commits, but under the hood it's more complicated than simply "storing diffs." Re: storing diffs, for anyone reading this that's interested, it does and it doesn't, depending on which level you're looking at. When you make a commit, git takes a snapshot of the entire repo at that point, so not just a diff. However, before storing it git then applies a compression algorithm to it that removes all the duplicate pieces, leaving it with only a diff of what's changed (without which the repo size would double each time you make a commit, which would suck). So git doesn't store diffs in the sense that after undoing the compression, each commit has a snapshot of the entire repo, but it does store diffs in the sense that what actually gets written to disk is a series of diffs. Said another way, git itself doesn't record commits as diffs, it records the entire contents of each file, but it compresses those records before storage to remove all duplicated parts leaving us with only storing the diffs. The benefit of this approach is that after decompression git doesn't have to follow the entire graph to rebuild the state at each commit the user is asking about, but in the end storage is efficient because you're only storing diffs at each point in time rather than duplicating the entire repo contents for each commit.