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