I've read that Git does not store file deltas. If this is true, how does it support file rollback to previous versions? If it's storing the entire file the repository space on disk must grow to be unmanageably large. Does Git support file rollbacks and diff(s) back to file version 1? Does it even suport a versioning concept as related to files? This is (I believe) essential to my understanding of a VCS/DVCS and my needs. I need to be able to compare what I'm about to check in with previous versions.
git does in fact save deltas of files, but it saves them as a delta of the whole file tree.
To see the differences between versions, do one of the following:
Git does not throw away information on its own*. All previous versions of every file are always available for reverts, diffs, inspections, et cetera.
Whole-tree versus Individual-files
What you may be trying to reconcile is the idea of accessing an old version of an individual file versus the fact that Git's history model is focused on the whole tree. Whole-tree versioning does require a bit more work to see (for example) the version of
The benefits of tree-orientation, chiefly the ability to view commits as a unit of interdependent changes made to various parts of the whole tree, general greatly outweigh the extra typing (which can be alleviated with aliases, scripts, et cetera) and CPU time spent digging through past commits.
When a new object (e.g. a file with previously unseen contents) enters the system, it is stored with plain (zlib) compression as a “loose object”. When enough loose objects accumulate (based on the
Objects in a pack file can be stored either as plain compressed data (same as a loose object, just bundled up with others objects), or as compressed deltas against some other object. Deltas can be chained together to configurable depths (
It is this aggressive delta compression (combined with normal zlib compression) that can often let a Git repository (with full history and an uncompressed working tree) take less space than a single SVN checkout (with uncompressed working tree and pristine copy).
* You can tell Git throw away commits by “rewriting history” and with commands like git reset, but even in these cases Git “hangs onto” the newly discarded commits for a while, just in case you decide that you need them. See git reflog and git prune.
It can be read on the same page:
Thus you can go back to previous revisions of a file and compare two files.