3 ms·

Well-said, although I disagree that it's "muddled". The data model is that commits are snapshots, and diffs between snapshots are computed as needed. The whole

Well-said, although I disagree that it's "muddled". The data model is that commits are snapshots, and diffs between snapshots are computed as needed. The whole system is designed around this. Packing is an implementation detail. The fact that internally it can store snapshots as diffs is more or less unrelated to the user-facing diffs. IMO it's confusing to even mention it in an educational context, except in response to the question of "how does Git prevent repo size from exploding?".

goku12 3y ago
> although I disagree that it's "muddled" I understand. I meant muddied (not muddled) in the sense that it can be confusing for beginners. For some reason, many long-time git users also don't seem to progress beyond the initial image they have. (That includes me too - I struggled with rebases for a long time). That description wasn't a criticism of the git model. Git model is clear if you take some time to study it. > Packing is an implementation detail. > The fact that internally it can store snapshots as diffs is more or less unrelated to the user-facing diffs. My point exactly! To summarize, a git user needs to remember only two things: 1. Git commits are modeled as snapshots of work tree. 2. Many operations are (user-facing) diff-based. Every other detail is a finer implementation detail that's good to know but not essential to get started.
- codeflo 3y ago
  The thing that's muddied for beginners are bad YouTube tutorials (which the internet is full of), not Git or the actual documentation. People should really read the Git documentation, it's very well-written and explains the correct mental model. Also, people really shouldn't teach implementation details to beginners. Or intermediates. Perhaps anyone who casually mentions that Git stores diffs to anyone not currently opening the source code for Git itself should be disqualified from ever giving explanations for technical stuff ever again.
  - goku12 3y ago
    I agree with your point about the official Git documentation. It is the only one I learned from and it's easy and comprehensive partly due to the involvement of actual git developers. But there is one area where I wish they stressed a bit more. Git documentation talks about the snapshot model so many times - you're never left in doubt how it's stored (including packing). But they don't stress particularly upon the fact that rebases, merges, cherrypicks and reverts are based on diffs (3-way merges). For example, I was expecting the 'drop' operation in interactive rebases to just delete that commit and leave all the subsequent commits intact (except for the DAG linkage). But to my surprise, the change introduced by that commit disappeared from all subsequent commits - leading me to suspect that they were using diffs in this stage. I eventually found a single confirmation of this in the official documents. But it's obscure. In fact, I tried and failed to find it for reference in this reply.
    - nerdponx 3y ago
      That's a great point, and I think we all agree that the documentation does a poor job of distinguishing between when the "snapshots" and the "diff" models are in use. But what is never exposed in the docs or user interface is the internal implementation details of how snapshots are stored. And that's what I was arguing is not one of Git's many documentation and UX problems.
    - seba_dos1 3y ago
      > But to my surprise, the change introduced by that commit disappeared from all subsequent commits - leading me to suspect that they were using diffs in this stage. Good way to think about rebase is that it's nothing more than automated reset and cherry-pick. You can rebase by hand without using `git rebase`, it's a convenience tool just like `git bisect`. `drop` does nothing, and removing the line does the same thing - it's just not cherry-picking that particular commit, skipping right to the next line. You can even add new lines to an interactive rebase and cherry-pick completely unrelated commits this way. Once you know how cherry-pick works, rebase (and revert) becomes clear too.
glandium 3y ago
> Packing is an implementation detail. It's so much of an implementation detail that even if the pack has a diff/delta between the two objects to diff, that WON'T be used to produce the output from git diff.
- cesarb 3y ago
  It's so much of an implementation detail, that git didn't have packing at first! All it had was loose objects ("disk space is cheap"). Packing was later added as an optimization, but the object model is still the same. It doesn't matter whether an object is in a pack file or not, it's treated the same.
aardvark179 3y ago
It’s confusing right up until it isn’t. If you rename a file, and edit it then it is helpful to understand that whether that is shown as a creation and a deletion or as a rename plus an edit is immaterial to some parts of git, and yet very important to others, and can change if you squash or rebase. Git’s abstractions are pretty leaky.

goku12 3y ago

> although I disagree that it's "muddled" I understand. I meant muddied (not muddled) in the sense that it can be confusing for beginners. For some reason, many long-time git users also don't seem to progress beyond the initial image they have. (That includes me too - I struggled with rebases for a long time). That description wasn't a criticism of the git model. Git model is clear if you take some time to study it. > Packing is an implementation detail. > The fact that internally it can store snapshots as diffs is more or less unrelated to the user-facing diffs. My point exactly! To summarize, a git user needs to remember only two things: 1. Git commits are modeled as snapshots of work tree. 2. Many operations are (user-facing) diff-based. Every other detail is a finer implementation detail that's good to know but not essential to get started.

codeflo 3y ago
The thing that's muddied for beginners are bad YouTube tutorials (which the internet is full of), not Git or the actual documentation. People should really read the Git documentation, it's very well-written and explains the correct mental model. Also, people really shouldn't teach implementation details to beginners. Or intermediates. Perhaps anyone who casually mentions that Git stores diffs to anyone not currently opening the source code for Git itself should be disqualified from ever giving explanations for technical stuff ever again.
- goku12 3y ago
  I agree with your point about the official Git documentation. It is the only one I learned from and it's easy and comprehensive partly due to the involvement of actual git developers. But there is one area where I wish they stressed a bit more. Git documentation talks about the snapshot model so many times - you're never left in doubt how it's stored (including packing). But they don't stress particularly upon the fact that rebases, merges, cherrypicks and reverts are based on diffs (3-way merges). For example, I was expecting the 'drop' operation in interactive rebases to just delete that commit and leave all the subsequent commits intact (except for the DAG linkage). But to my surprise, the change introduced by that commit disappeared from all subsequent commits - leading me to suspect that they were using diffs in this stage. I eventually found a single confirmation of this in the official documents. But it's obscure. In fact, I tried and failed to find it for reference in this reply.
  - nerdponx 3y ago
    That's a great point, and I think we all agree that the documentation does a poor job of distinguishing between when the "snapshots" and the "diff" models are in use. But what is never exposed in the docs or user interface is the internal implementation details of how snapshots are stored. And that's what I was arguing is not one of Git's many documentation and UX problems.
  - seba_dos1 3y ago
    > But to my surprise, the change introduced by that commit disappeared from all subsequent commits - leading me to suspect that they were using diffs in this stage. Good way to think about rebase is that it's nothing more than automated reset and cherry-pick. You can rebase by hand without using `git rebase`, it's a convenience tool just like `git bisect`. `drop` does nothing, and removing the line does the same thing - it's just not cherry-picking that particular commit, skipping right to the next line. You can even add new lines to an interactive rebase and cherry-pick completely unrelated commits this way. Once you know how cherry-pick works, rebase (and revert) becomes clear too.

glandium 3y ago

> Packing is an implementation detail. It's so much of an implementation detail that even if the pack has a diff/delta between the two objects to diff, that WON'T be used to produce the output from git diff.

cesarb 3y ago
It's so much of an implementation detail, that git didn't have packing at first! All it had was loose objects ("disk space is cheap"). Packing was later added as an optimization, but the object model is still the same. It doesn't matter whether an object is in a pack file or not, it's treated the same.

aardvark179 3y ago

It’s confusing right up until it isn’t. If you rename a file, and edit it then it is helpful to understand that whether that is shown as a creation and a deletion or as a rename plus an edit is immaterial to some parts of git, and yet very important to others, and can change if you squash or rebase. Git’s abstractions are pretty leaky.