Version Control with Git

Comparing How Subversion and Git Derive diffs

Most systems, such as CVS or Subversion, track a series of revisions and store just the changes between each pair of files. This technique is meant to save storage space and overhead.

Internally, such systems spend a lot of time thinking about things like the series of changes between A and B. When you update your files from the central repository, for example, Subversion remembers that the last time you updated the file you were at revision r1095, but now the repository is at revision r1123. Thus, the server must send you the diff between r1095 and r1123. Once your Subversion client has these diffs, it can incorporate them into your working copy and produce r1123. (That’s how Subversion avoids sending you all the contents of all files every time you update.)

To save disk space, Subversion also stores its own repository as a series of diffs on the server. When you ask for the diffs between r1095 and r1123, it looks up all the individual diffs for each version between those two versions, merges them together into one large diff, and sends you the result. But Git doesn’t work like that.

In Git, as you’ve seen, each commit contains a tree, which is a list of files contained by that commit. Each tree is independent of all other trees. Git users still talk about diffs and patches, of course, since these are still extremely useful. Yet, in Git a diff and a patch are derived data, not the fundamental data they are in CVS or Subversion. If you ...