What are the advantages/disadvantages of Git's snapshot-based approach in practice compared to the traditional VCSs?

Question

In the official git book I can read this:

Git thinks about its data more like a stream of snapshots. This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS. We’ll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in Git Branching.

What difference does this make in practice? In the book it says that the benefits will be covered in the branching topic but it is not mentioned there and I do not see why this is important. For example I can create branches in SVN, I can create patches (like cherry picking) and so on. So why is the snapshot behavior useful compared to say SVN?

Note that I really like Git and I have no intention of bashing it I just wish to understand it better.

Answer 1

One of the main advantages remains in term of merging, a domain where SVN struggles at time.
(see "How and/or why is merging in Git better than in SVN?")

You combine the graph of commits (DAG) representing branches (instead of the SVN subtrees) and the snapshot representation associated with each commit:

From Pro Git Book:

Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two.

Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it. This is referred to as a merge commit, and is special in that it has more than one parent.

Answer 2

Your question is a bit unclear because - generally speaking - both Apache Subversion and Git are snapshot-based. However, Git's model is a bit different. Git thinks about its data more like a stream of snapshots. This is an important distinction between Git and nearly all other VCSs. But at the same time Git is not totally snapshot-based because it stores deltas between revisions as does Subversion too. Therefore, I don't understand what kind of advantages or disadvantages you want to hear about snapshot-based model vs X model.

However, there is still one major disadvantage in Git's model -- it is possible to lose revision history completely. With Git - for example - once you delete branch that had been never merged, there will be no pointers to the commits contained in this branch anymore. In such case garbage collection will do its job and will remove the commits without any pointers from the repository history. Forever.

The git model expects that most branches most people have will remain private to one repository, will be merged or rebased, fully or partially, onto some other branch, will then be abandoned, and will later be garbage-collected.

However, in some cases I'd want to have the entire history of my codebase. Even if someone removes branch with some unfinished or erroneous work, I want to be able to access it in the future.

On the contrary, with centralized system such as Subversion it is very hard (or even impossible) to remove data that has been committed to a repository. The revisions in Subversion repository history are immutable.