4 ms·

It’s not a meme, it’s explained in one of the first chapters of the official documentation, in a section titled “snapshots, not differences”: https://git-scm.co

It’s not a meme, it’s explained in one of the first chapters of the official documentation, in a section titled “snapshots, not differences”: https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3... You and some others in this comment section are simply wrong about this. Everybody is wrong sometimes, that’s no problem. But your righteous tone (“meme”, “amazes me”) after clearly having spent zero minutes of research is not what I would consider a constructive way to engage in a discussion.

tomn 3y ago
Yeah, i'm sorry about the tone, that wasn't my intent. By meme, i don't mean that it's wrong, it isn't, just that in my opinion it's a thing that people like to repeat because they have heard others say it. That's my only explanation for why someone would say "at the user interface level, Git stores snapshots" when the interface is, i think clearly, mostly about working with commits as changes. > You and some others in this comment section are simply wrong about this. Everybody is wrong sometimes, that’s no problem. About what, exactly? As far as i know, what i wrote is factually accurate (or an opinion, which can not be wrong). Yes, the git manual writes about snapshots, because it's literally true (and sometimes necessary to understand), but it also repeatedly refers to commits as changes, because that is a helpful and equivalent way to think about commits, modulo some details which mostly don't matter.
- codeflo 3y ago
  > That's my only explanation for why someone would say "at the user interface level, Git stores snapshots" when the interface is, i think clearly, mostly about working with commits as changes. That's what the documentation says, no need to assume a conspiracy. I don't know on what authority you claim to know better, you haven't cited anything. > About what, exactly? As far as i know, what i wrote is factually accurate (or an opinion, which can not be wrong). Opinions about facts can be wrong. I've cited the source, maybe you have a better one than the official documentation, but you haven't given it. > Yes, the git manual writes about snapshots, because it's literally true (and sometimes necessary to understand), but it also repeatedly refers to commits as changes But it doesn't. Again, you didn't cite anything. Conceptually, and in the documentation, changes are always something that's computed after the fact. I've triple checked just now, the official documentation always talks about the changes between commits, or the change introduced by a commit (which means the changes to the parent commit) -- that's fine and in fact exactly the point. It never uses "commit" as a synonym for "change", or claims that a commit somehow stores a change.
  - tomn 3y ago
    > the official documentation always talks about the changes between commits, or the change introduced by a commit (which means the changes to the parent commit) That's exactly what i was referring to. If you have a commit, that is both a snapshot (as stored in the tree reference) and a change (because it has references to parent commits, which are also snapshots). Of course the wording is factually accurate, but it refers to computing the change, because that's how it is best explained, and how those commands (rebase/cherry-pick/revert) work conceptually. If you try to understand those commands without thinking about diffs, you can come unstuck. Commands like reset of course don't talk about changes, because that's not relevant for how they work. Understanding both models and their equivalence is helpful, IMO.

tomn 3y ago

Yeah, i'm sorry about the tone, that wasn't my intent. By meme, i don't mean that it's wrong, it isn't, just that in my opinion it's a thing that people like to repeat because they have heard others say it. That's my only explanation for why someone would say "at the user interface level, Git stores snapshots" when the interface is, i think clearly, mostly about working with commits as changes. > You and some others in this comment section are simply wrong about this. Everybody is wrong sometimes, that’s no problem. About what, exactly? As far as i know, what i wrote is factually accurate (or an opinion, which can not be wrong). Yes, the git manual writes about snapshots, because it's literally true (and sometimes necessary to understand), but it also repeatedly refers to commits as changes, because that is a helpful and equivalent way to think about commits, modulo some details which mostly don't matter.

codeflo 3y ago
> That's my only explanation for why someone would say "at the user interface level, Git stores snapshots" when the interface is, i think clearly, mostly about working with commits as changes. That's what the documentation says, no need to assume a conspiracy. I don't know on what authority you claim to know better, you haven't cited anything. > About what, exactly? As far as i know, what i wrote is factually accurate (or an opinion, which can not be wrong). Opinions about facts can be wrong. I've cited the source, maybe you have a better one than the official documentation, but you haven't given it. > Yes, the git manual writes about snapshots, because it's literally true (and sometimes necessary to understand), but it also repeatedly refers to commits as changes But it doesn't. Again, you didn't cite anything. Conceptually, and in the documentation, changes are always something that's computed after the fact. I've triple checked just now, the official documentation always talks about the changes between commits, or the change introduced by a commit (which means the changes to the parent commit) -- that's fine and in fact exactly the point. It never uses "commit" as a synonym for "change", or claims that a commit somehow stores a change.
- tomn 3y ago
  > the official documentation always talks about the changes between commits, or the change introduced by a commit (which means the changes to the parent commit) That's exactly what i was referring to. If you have a commit, that is both a snapshot (as stored in the tree reference) and a change (because it has references to parent commits, which are also snapshots). Of course the wording is factually accurate, but it refers to computing the change, because that's how it is best explained, and how those commands (rebase/cherry-pick/revert) work conceptually. If you try to understand those commands without thinking about diffs, you can come unstuck. Commands like reset of course don't talk about changes, because that's not relevant for how they work. Understanding both models and their equivalence is helpful, IMO.