Conceptually, a git commit is a snapshot. Simple as that. The user doesn't need to worry about how git manages its data internally.
> I believe that Git becomes understandable if we peel back the curtain and look at how Git stores your repository data.
This strikes me as misleading in the same way this StackOverflow answer [0] is misleading. In terms of how git stores data, commits are not always snapshots. Internally, git sometimes uses delta compression to reduce storage space. This is of no concern to the user, conceptually a commit is still a snapshot, but it's just not true that git naively stores each commit as a full snapshot.
Peeling back the curtain isn't helpful to someone trying to understand the basic git model. Also, as the article makes no mention of delta compression or of 'packfiles', it seems to me it hasn't pulled back the curtain at all.
> I believe that Git becomes understandable if we peel back the curtain and look at how Git stores your repository data.
This strikes me as misleading in the same way this StackOverflow answer [0] is misleading. In terms of how git stores data, commits are not always snapshots. Internally, git sometimes uses delta compression to reduce storage space. This is of no concern to the user, conceptually a commit is still a snapshot, but it's just not true that git naively stores each commit as a full snapshot.
Peeling back the curtain isn't helpful to someone trying to understand the basic git model. Also, as the article makes no mention of delta compression or of 'packfiles', it seems to me it hasn't pulled back the curtain at all.
[0] https://stackoverflow.com/a/8198276/