The logical model of Git doesn't store changesets or diffs at all. The logical structure of a commit is: 1. Some "human" metadata such as message, author, time

The logical model of Git doesn't store changesets or diffs at all. The logical structure of a commit is: 1. Some "human" metadata such as message, author, timestamps 2. An ordered list of parents (0 to infinity parents) 3. A complete directory tree of the repository at that version. So when you reference a commit in Git you aren't referencing a diff/changeset. You are referencing an exact snapshot of the files in the repository at that time. This is sometimes obscured because to a human we often find it useful to see what changes a commit introduced. For example if you run `git show $commit` in the simple case where $commit has exactly one parent Git will compute a diff between $commit and its parent ($commit~1). However logically this diff isn't stored as part of the repository, it is computed on the fly from the snapshots of the two directory trees. If you want to re-apply it to a different version of the repo (usually via `git cherry-pick`) Git basically does two steps: 1. Compute the diff between the commit and its parent. 2. Apply that diff to the target revision. Of course this all gets more complicated in the case of merge commits (commits with >1 parent) but the model is similar. (For performance reasons Git does use delta compression internally but that is just an optimization and doesn't really reflect the diffs that humans are interested in).