3 ms·

If git did rebuild the graph, right from the very first commit, the end result of the operation would look identical to the user as it does now. It seems to me

If git did rebuild the graph, right from the very first commit, the end result of the operation would look identical to the user as it does now. It seems to me the two mental models are interchangeable when it comes to the use of git from the users point of view. What is missing, from the users point of view, when they model commits as diffs+parents vs as snapshots? Now I think about it, it's probably that users have a bad understanding of the commit-as-diff models; they could similarly have a bad understanding of the commit-as-snapshot model I expect, I don't know that thinking in snapshots helps to understand git from an users point of view better than thinking (properly) in diffs. The article for example explains that any two commits can be differenced because the underlying snapshot trees can be compared, but the commit-as-diff model can as easily explain why comparing two commits works by tracing each commit back to the common base commit - so the commit-as-diff mental model just needs to remember that commits are fundamentally tied to the path they have back to the root commit. It seems to me if you take the diagrams from the article and remove the under-the-covers stuff leaving just the circles, the commits-as-diffs and commits-as-snapshots models look exactly the same.

haberman 6y ago
> What is missing, from the users point of view, when they model commits as diffs+parents vs as snapshots? With the wrong mental model it's harder to predict what operations are expensive. If "git checkout <SHA>" truly did have to replay all diffs from the beginning of time, it would be a very expensive operation that is best avoided unless you absolutely need it. But in practice it is a very fast operation (one of the fastest) that there is no need to shy away from.
- taberiand 6y ago
  A fair point possibly, but given checkout/switching branches is probably just about the most common action when working with git repos, I'd hope people would notice that it's fast pretty quickly.
JoshuaDavid 6y ago
Merge commits are a bit hard to understand from the perspective of "a commit is basically just a parent commit plus diff". On the flip side, cherry-picking is hard to understand from the perspective of "a commit is basically just a snapshot, nothing more" (it's _also_ weird from the parent-commit-plus-diff perspective -- cherry-pick is kind of a weird operation, but useful enough that we keep it anyway despite it not fitting quite as cleanly into the git model as other operations). Outside those edge cases, though, people with "snapshot" and "parent + diff" mental models will make basically identical predictions about what the results of various operations with git will be.
- zaarn 6y ago
  The solution is to think of it as "it's both, snapshot and parent + diff". When you cherry-pick, git is using the parent+diff model to move the commit. When you do a merge commit, it's using the snapshot model.

haberman 6y ago

> What is missing, from the users point of view, when they model commits as diffs+parents vs as snapshots? With the wrong mental model it's harder to predict what operations are expensive. If "git checkout <SHA>" truly did have to replay all diffs from the beginning of time, it would be a very expensive operation that is best avoided unless you absolutely need it. But in practice it is a very fast operation (one of the fastest) that there is no need to shy away from.

taberiand 6y ago
A fair point possibly, but given checkout/switching branches is probably just about the most common action when working with git repos, I'd hope people would notice that it's fast pretty quickly.

JoshuaDavid 6y ago

Merge commits are a bit hard to understand from the perspective of "a commit is basically just a parent commit plus diff". On the flip side, cherry-picking is hard to understand from the perspective of "a commit is basically just a snapshot, nothing more" (it's _also_ weird from the parent-commit-plus-diff perspective -- cherry-pick is kind of a weird operation, but useful enough that we keep it anyway despite it not fitting quite as cleanly into the git model as other operations). Outside those edge cases, though, people with "snapshot" and "parent + diff" mental models will make basically identical predictions about what the results of various operations with git will be.

zaarn 6y ago
The solution is to think of it as "it's both, snapshot and parent + diff". When you cherry-pick, git is using the parent+diff model to move the commit. When you do a merge commit, it's using the snapshot model.