5 ms·

Agreed, that's my point why the diff model isn't helpful at all to think about.

ghusbands 3y ago
You claimed the diff was stored - that's what the correction is about. Git's primary storage model is of complete snapshots.
- sho_hn 3y ago
  https://tom.preston-werner.com/2009/05/19/the-git-parable.html https://tom.preston-werner.com/2009/05/19/the-git-parable.ht... Tom's 15 years old text remains the only correct, useful, easy to understand explanation of the why and how of git I've ever popularly encountered. Post like the OP's do far more harm than good by introducing mental models comprised of best-effort confused half-knowledge. If (generic) you ever wanted to "really learn git", do yourself a favor and read it.
MrDarcy 3y ago
When we ask git to show us a commit, it shows us a diff, because that’s the most helpful model.
- yencabulator 3y ago
  If we want to ask git to show us a commit, we need to type git cat-file commit HEAD `git show` does not "show a commit" as such, its man page is pretty clear about that: For commits it shows the log message and textual diff.
  - MrDarcy 3y ago
    That’s exactly the point. git show HEAD shows the log and textual diff because that’s what matters most from the users perspective. The internal representation doesn’t matter for most users and use cases.
hibbelig 3y ago
> Agreed, that's my point why the diff model isn't helpful at all to think about. Similar to the particle-wave duality in physics, a commit is both a snapshot and a diff, and similar to physics, which way to look at it depends on context. For example, if you are rebasing branch A onto branch B, then you will want to look at the current state of branch B (the snapshot model) plus the diffs of the relevant commits from branch A (the diff model). You will get nowhere fast if you try to look at branch A using the snapshot model. (And looking at branch B using the diff model will drive you insane.) How git stores the data is orthogonal to that, I kind of know in the back of my head but I don't really care too much. It's enough that git gives me access to both the snapshot and the diff aspect of a commit.
- seba_dos1 3y ago
  Rebasing is nothing more than doing operations on a graph of snapshots, most notably cherry-picking (which is defined in terms of a given commit and its parent). Snapshots are not "how git stores the data", it's not a technical detail; they are the central data structure you're operating on conceptually - also when what you end up with is a calculated diff (which you can easily calculate between any two commits, even those topologically unrelated).
  - tomn 3y ago
    Git could just as well store commits as diffs from other commits, and 99% of users would never notice. It uses snapshots because that is efficient, but from a user perspective all common git operations look more like they are operating on diffs than snapshots. When you cherry-pick a commit, the diff of the old and new commit will be similar, but the snapshots are normally completely different; that's the point. The same goes for rebasing, which is like applying a set of patches. Heck, if it goes wrong, you get merge conflicts, which wouldn't happen if you were just manipulating pointers between snapshots. Git actually makes it quite difficult to manipulate commits as pointers to snapshots instead of diffs -- i doubt most git users even know about `git commit-tree`. This is why i don't really get the "git is wrong and should work on diffs" crowd. If it did, the user experience would be 99% the same, unless you're manually editing your diffs before committing them.

You claimed the diff was stored - that's what the correction is about. Git's primary storage model is of complete snapshots.

sho_hn 3y ago
https://tom.preston-werner.com/2009/05/19/the-git-parable.html https://tom.preston-werner.com/2009/05/19/the-git-parable.ht... Tom's 15 years old text remains the only correct, useful, easy to understand explanation of the why and how of git I've ever popularly encountered. Post like the OP's do far more harm than good by introducing mental models comprised of best-effort confused half-knowledge. If (generic) you ever wanted to "really learn git", do yourself a favor and read it.

MrDarcy 3y ago

When we ask git to show us a commit, it shows us a diff, because that’s the most helpful model.

yencabulator 3y ago
If we want to ask git to show us a commit, we need to type git cat-file commit HEAD `git show` does not "show a commit" as such, its man page is pretty clear about that: For commits it shows the log message and textual diff.
- MrDarcy 3y ago
  That’s exactly the point. git show HEAD shows the log and textual diff because that’s what matters most from the users perspective. The internal representation doesn’t matter for most users and use cases.

hibbelig 3y ago

> Agreed, that's my point why the diff model isn't helpful at all to think about. Similar to the particle-wave duality in physics, a commit is both a snapshot and a diff, and similar to physics, which way to look at it depends on context. For example, if you are rebasing branch A onto branch B, then you will want to look at the current state of branch B (the snapshot model) plus the diffs of the relevant commits from branch A (the diff model). You will get nowhere fast if you try to look at branch A using the snapshot model. (And looking at branch B using the diff model will drive you insane.) How git stores the data is orthogonal to that, I kind of know in the back of my head but I don't really care too much. It's enough that git gives me access to both the snapshot and the diff aspect of a commit.

seba_dos1 3y ago
Rebasing is nothing more than doing operations on a graph of snapshots, most notably cherry-picking (which is defined in terms of a given commit and its parent). Snapshots are not "how git stores the data", it's not a technical detail; they are the central data structure you're operating on conceptually - also when what you end up with is a calculated diff (which you can easily calculate between any two commits, even those topologically unrelated).
- tomn 3y ago
  Git could just as well store commits as diffs from other commits, and 99% of users would never notice. It uses snapshots because that is efficient, but from a user perspective all common git operations look more like they are operating on diffs than snapshots. When you cherry-pick a commit, the diff of the old and new commit will be similar, but the snapshots are normally completely different; that's the point. The same goes for rebasing, which is like applying a set of patches. Heck, if it goes wrong, you get merge conflicts, which wouldn't happen if you were just manipulating pointers between snapshots. Git actually makes it quite difficult to manipulate commits as pointers to snapshots instead of diffs -- i doubt most git users even know about `git commit-tree`. This is why i don't really get the "git is wrong and should work on diffs" crowd. If it did, the user experience would be 99% the same, unless you're manually editing your diffs before committing them.