4 ms·

Even the fact that it's snapshots (but possibly compressed) is an implementation detail. I actually really like the generalized "smallest/fastest/simplest way

by krupan 3y ago

Even the fact that it's snapshots (but possibly compressed) is an implementation detail. I actually really like the generalized "smallest/fastest/simplest way to create new file from old file" explanation. "Fastest" was a primary goal of git. Same with Mercurial. Other distributed revision control tools that were designed around the same time (bzr, darcs) didn't optimize for speed and you could tell.

searealist 3y ago
I disagree, snapshots is the fundamental model. Otherwise, shallow clones would not be possible.
- usr1106 3y ago
  Of course they would be possible, just harder and less efficient to implement. The snapshot representation can be transformed into a chain of diffs representation and the other way round without losing anything except performance.
codeflo 3y ago
> I actually really like the generalized "smallest/fastest/simplest way to create new file from old file" explanation. You might like that explanation because it fits a mental model you may have acquired previously, but at the user interface level, Git stores snapshots. It's not an implementation detail, it's what the entire command line is based on.
- DiggyJohnson 3y ago
  Aren’t there situations with divergent branches where you end up wanting to apply or rewind commits but cannot do so because applying that function is invalid because the difference between commits is just that, a difference, and not a full snapshot of the repository.
  - fl7305 3y ago
    No, the previous post above is correct: > Each commit contains a complete exact snapshot of the entire repository. On the other hand it does contain optimizations to reduce the size of these snapshots in the form of git packs I think the problem that you describe is that the divergent branches have made changes in the same file that cannot be automatically reconciled?
- DannyBee 3y ago
  Basically all atomic-commit based VCs store snapshots. That's how they achieve atomic commits. Git is copy-on-write, so it's not storing full snapshots either, because it's space prohibitive. All of the storage mechanisms (deltas, etc) are time/space tradeoffs. I don't think there is anything odd about that? It's true in lots of things beyond VCen
- tomn 3y ago
  > at the user interface level, Git stores snapshots Where in the user interface? All the common commands act like they are working with diffs. It amazes me that people keep repeating this (there's another thread of the same stuff here https://news.ycombinator.com/item?id=38896658#38897488 https://news.ycombinator.com/item?id=38896658#38897488 ). It's like "actually git commits are snapshots not diffs" is such a powerful meme that those who repeat it forget about their day-to-day experience of working with git, in which it tries as hard as possible to hide the snapshots, and let you work with diffs. The onion really has three layers: 2) In the user interface, all common commands work as if commits store a reference to a parent commit and a diff. 1) Commits actually store a reference to a tree (snapshot) and a parent commit; diffs are generated on-demand. 0) Trees (snapshots) may actually be stored in different ways, where "smallest/fastest/simplest way to create new file from old file" makes sense. Most people live comfortably on layer two. Occasionally you might need to know about layer 1 to do something weird, and layer 0 is only really for people interested in implementation details.
  - codeflo 3y ago
    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.
juped 3y ago
It's _a_ way that an algorithm found out of the infinitely many edit scripts representing the same change; the underlying nitpick in this thread is that an algorithm found it and maybe it's not a great choice (we've likely all seen diff algorithms making some odd choices in the presence of closing braces, for example). But there's not particularly any adjectives to be expected about it.

by krupan 3y ago

searealist 3y ago

I disagree, snapshots is the fundamental model. Otherwise, shallow clones would not be possible.

usr1106 3y ago
Of course they would be possible, just harder and less efficient to implement. The snapshot representation can be transformed into a chain of diffs representation and the other way round without losing anything except performance.

codeflo 3y ago

> I actually really like the generalized "smallest/fastest/simplest way to create new file from old file" explanation. You might like that explanation because it fits a mental model you may have acquired previously, but at the user interface level, Git stores snapshots. It's not an implementation detail, it's what the entire command line is based on.

DiggyJohnson 3y ago
Aren’t there situations with divergent branches where you end up wanting to apply or rewind commits but cannot do so because applying that function is invalid because the difference between commits is just that, a difference, and not a full snapshot of the repository.
- fl7305 3y ago
  No, the previous post above is correct: > Each commit contains a complete exact snapshot of the entire repository. On the other hand it does contain optimizations to reduce the size of these snapshots in the form of git packs I think the problem that you describe is that the divergent branches have made changes in the same file that cannot be automatically reconciled?
DannyBee 3y ago
Basically all atomic-commit based VCs store snapshots. That's how they achieve atomic commits. Git is copy-on-write, so it's not storing full snapshots either, because it's space prohibitive. All of the storage mechanisms (deltas, etc) are time/space tradeoffs. I don't think there is anything odd about that? It's true in lots of things beyond VCen
tomn 3y ago
> at the user interface level, Git stores snapshots Where in the user interface? All the common commands act like they are working with diffs. It amazes me that people keep repeating this (there's another thread of the same stuff here https://news.ycombinator.com/item?id=38896658#38897488 https://news.ycombinator.com/item?id=38896658#38897488 ). It's like "actually git commits are snapshots not diffs" is such a powerful meme that those who repeat it forget about their day-to-day experience of working with git, in which it tries as hard as possible to hide the snapshots, and let you work with diffs. The onion really has three layers: 2) In the user interface, all common commands work as if commits store a reference to a parent commit and a diff. 1) Commits actually store a reference to a tree (snapshot) and a parent commit; diffs are generated on-demand. 0) Trees (snapshots) may actually be stored in different ways, where "smallest/fastest/simplest way to create new file from old file" makes sense. Most people live comfortably on layer two. Occasionally you might need to know about layer 1 to do something weird, and layer 0 is only really for people interested in implementation details.
- codeflo 3y ago
  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.

juped 3y ago

It's _a_ way that an algorithm found out of the infinitely many edit scripts representing the same change; the underlying nitpick in this thread is that an algorithm found it and maybe it's not a great choice (we've likely all seen diff algorithms making some odd choices in the presence of closing braces, for example). But there's not particularly any adjectives to be expected about it.