3 ms·

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 become

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. [0] https://stackoverflow.com/a/8198276/ https://stackoverflow.com/a/8198276/

stolee 6y ago
The delta compression in Git is about storing the file contents of an object as a diff against another object. This changes the literal size on-disk, but it doesn't change the logical unit. In fact, the delta chains used by Git for space compression have no direct relation to the object model DAG. From the perspective of a user using Git, these deltas are completely invisible. Edit: perhaps to help this point... If Git stores an object using a delta, that doesn't change the object ID of that object compared to storing it uncompressed.
- MaxBarraclough 6y ago
  Respectfully, I already made all of those points quite explicitly.
- tsimionescu 6y ago
  Git internal delta compression has nothing to do with why Git commits are most usefully thought of as diffs. All git operations start by computing diffs between commits, and then trying to apply those diffs before conceptually taking a snapshot. It is quite likely that the textual diff used in the operation and the internal diff produced by the delta compression are entirely different.
deleted 6y ago
[deleted]
tsimionescu 6y ago
> Conceptually, a git commit is a snapshot. Simple as that. The user doesn't need to worry about how git manages its data internally. This "simple" model is completely useless when trying to understand what merges, cherry picks, rebases, and patches actually do. Snapshots don't naturally do anything, and can't be combined in any way. If you think in terms of snapshots, then you have to also start thinking about diff algorithms, and how different diff algorithms can give completely different meanings to what a "merge" or a "rebase" actually mean. Which is true, but given that git comes with one specific diff algorithm built in, and beginners should DEFINITELY not mess with it, it muddies the waters quite a bit.

stolee 6y ago

The delta compression in Git is about storing the file contents of an object as a diff against another object. This changes the literal size on-disk, but it doesn't change the logical unit. In fact, the delta chains used by Git for space compression have no direct relation to the object model DAG. From the perspective of a user using Git, these deltas are completely invisible. Edit: perhaps to help this point... If Git stores an object using a delta, that doesn't change the object ID of that object compared to storing it uncompressed.

MaxBarraclough 6y ago
Respectfully, I already made all of those points quite explicitly.
tsimionescu 6y ago
Git internal delta compression has nothing to do with why Git commits are most usefully thought of as diffs. All git operations start by computing diffs between commits, and then trying to apply those diffs before conceptually taking a snapshot. It is quite likely that the textual diff used in the operation and the internal diff produced by the delta compression are entirely different.

deleted 6y ago

[deleted]

tsimionescu 6y ago

> Conceptually, a git commit is a snapshot. Simple as that. The user doesn't need to worry about how git manages its data internally. This "simple" model is completely useless when trying to understand what merges, cherry picks, rebases, and patches actually do. Snapshots don't naturally do anything, and can't be combined in any way. If you think in terms of snapshots, then you have to also start thinking about diff algorithms, and how different diff algorithms can give completely different meanings to what a "merge" or a "rebase" actually mean. Which is true, but given that git comes with one specific diff algorithm built in, and beginners should DEFINITELY not mess with it, it muddies the waters quite a bit.