5 ms·

> Instead, what is stored is "what is the smallest/fastest/simplest way to create new file from old file". I think this may be misleading to people reading you

> Instead, what is stored is "what is the smallest/fastest/simplest way to create new file from old file". I think this may be misleading to people reading your comment. Git is a snapshot based version control system (Maybe you know this). 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, and in that sense your comment is technically true, but this is really just an implementation detail.

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.
- 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.
DannyBee 3y ago
I"m not sure why it's misleading? I said smallest/simplest/fastest. Fastest is fulltext or pointers to existing objects. Smallest is deltas from other objects. If your complaint is that i'm somehow implying it's file based, i'm not. But as we'll see, your claim that it stores complete exact snapshots is wrong. It is correct at the UI level, but we aren't talking about the UI level, but the storage level. Git is object based, where most objects are files are directories, and it does in fact choose between fastest/smallest/simplest to decide how to represent changes between trees. One way it reduces space is to be copy-on-write, which is why it doesn't store exact snapshots. I do know git (at the ui level) is snapshot based - i worked on VC systems for about a a decade, and remember when git was born. I also used to sit next to Shawn Pearce (RIP :( )and Junio Hamano's office for 7 or 8 years, so i acquired lots of git knowledge by osmosis. On my own I go far enough back to have watched Graydon work on monotone before rust ;) You are correct it is a snapshot based VC, but all parts of the storage are implementation details as well. The last non-snapshot based VC to have serious followership was CVS, which used individual RCS files and non-atomic commits. With atomic commits came snapshots. Even SVN was a snapshot based VC as well - SVN servers stored things abstractly the same as Git does - each commit was a copy of the entire FS, with pointers to unchanged objects. More importantly Git is copy-on-write, so it also doesn't store the complete exact snapshot of the entire repository. it stores the changed objects since the last tree, with pointers into that last tree for unchanged objects. So what you wrote is not correct either. This is why, say, corruption in older commits can break newer commits. This is also theoretically an implementation detail. As mentioned SVN had an FS abstraction that presented each commit to the rest of the system as a copy of the filesystem, like git does. The different storage backends under FS chose to store the FS in different ways - some deltas, some plaintext, some pointers to existing plaintext. However, none of these VC would be really useful if they didn't trade time for space. If they actually stored "a complete exact snapshot", the space usage would be insane. To whit - a "complete exact snapshot of the entire repository" would be space-prohibitive. the kernel tree has over 1 million commits and the tree is ~4 gigabytes. Without some of the "implementation details", it would be unusable (since this is 4PB, i'm going to assume the fact it was smaller in the past is in the noise). All storage in VCen is an implementation detail. Git exposes its implementation details more to users than others do. Git doesn't really have clean abstractions, and because it abstraction breaks at various levels, it's hard to talk about in the way we are here without saying something that is "wrong" at some level. For example, git is really object based, not snapshot based, at the lower levels. It's basically an object store of different types of objects, some of them trees, etc. To the user, it appears mostly snapshot based, but you can go mess with the objects in various ways. SVN (again, for example), has as it's main abstraction is an FS snapshot, and the files/directories/things in it. There is no access to a lower level abstraction like you can in git. This is actually snapshot based - there is no abstraction breaking.

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.
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.

DannyBee 3y ago

I"m not sure why it's misleading? I said smallest/simplest/fastest. Fastest is fulltext or pointers to existing objects. Smallest is deltas from other objects. If your complaint is that i'm somehow implying it's file based, i'm not. But as we'll see, your claim that it stores complete exact snapshots is wrong. It is correct at the UI level, but we aren't talking about the UI level, but the storage level. Git is object based, where most objects are files are directories, and it does in fact choose between fastest/smallest/simplest to decide how to represent changes between trees. One way it reduces space is to be copy-on-write, which is why it doesn't store exact snapshots. I do know git (at the ui level) is snapshot based - i worked on VC systems for about a a decade, and remember when git was born. I also used to sit next to Shawn Pearce (RIP :( )and Junio Hamano's office for 7 or 8 years, so i acquired lots of git knowledge by osmosis. On my own I go far enough back to have watched Graydon work on monotone before rust ;) You are correct it is a snapshot based VC, but all parts of the storage are implementation details as well. The last non-snapshot based VC to have serious followership was CVS, which used individual RCS files and non-atomic commits. With atomic commits came snapshots. Even SVN was a snapshot based VC as well - SVN servers stored things abstractly the same as Git does - each commit was a copy of the entire FS, with pointers to unchanged objects. More importantly Git is copy-on-write, so it also doesn't store the complete exact snapshot of the entire repository. it stores the changed objects since the last tree, with pointers into that last tree for unchanged objects. So what you wrote is not correct either. This is why, say, corruption in older commits can break newer commits. This is also theoretically an implementation detail. As mentioned SVN had an FS abstraction that presented each commit to the rest of the system as a copy of the filesystem, like git does. The different storage backends under FS chose to store the FS in different ways - some deltas, some plaintext, some pointers to existing plaintext. However, none of these VC would be really useful if they didn't trade time for space. If they actually stored "a complete exact snapshot", the space usage would be insane. To whit - a "complete exact snapshot of the entire repository" would be space-prohibitive. the kernel tree has over 1 million commits and the tree is ~4 gigabytes. Without some of the "implementation details", it would be unusable (since this is 4PB, i'm going to assume the fact it was smaller in the past is in the noise). All storage in VCen is an implementation detail. Git exposes its implementation details more to users than others do. Git doesn't really have clean abstractions, and because it abstraction breaks at various levels, it's hard to talk about in the way we are here without saying something that is "wrong" at some level. For example, git is really object based, not snapshot based, at the lower levels. It's basically an object store of different types of objects, some of them trees, etc. To the user, it appears mostly snapshot based, but you can go mess with the objects in various ways. SVN (again, for example), has as it's main abstraction is an FS snapshot, and the files/directories/things in it. There is no access to a lower level abstraction like you can in git. This is actually snapshot based - there is no abstraction breaking.