another thing I'm trying to figure out about git is that -- many people think of commits as being diffs. Technically in git commits are snapshots.
but I can't tell if it's important to understand that git commits are "really" implemented as snapshots instead of diffs. Does it actually matter? Why?
(commits are treated in different ways by diff commands: `git cherry-pick` treats a commit as a diff, `git checkout` treats it as a snapshot, `git log` treats it as a history)
(1/?)
reasons folks mentioned why it might be useful to understand a git commit is a snapshot & not a diff so far:
* it explains why git is weird about file renames (it's just guessing that the file was renamed)
* merge commits make much more sense when you think of them as snapshots (if commits are diffs, how could a commit have 2 parents??)
* it tells you that having gigantic files that you're constantly making small changes to is bad
(2/?)
@b0rk It gives a somewhat better intuition for the meaning of commit range a..b for cases where b is a descendant of a -- the range corresponds to the diff between a and b regardless of any multiparented commits present (this does break down if the commits are not descendants of each other, but if you combine that with merge commits, the interpretation of ranges gets hopelessly confusing anyway).
It also reinforces the fact that when you rebase/cherrypick a commit, you get a brand new commit with no obvious relationship with the original one (even if the diff is identical) other than the similarity in the diff to parent. That helps with understanding how one should go about rebasing a sequence of branches built on top of each other (or at least why some approaches cause one to be asked to resolve the same merge conflicts multiple times and/or be asked to resolve merge conflicts of a commit with itself).
