Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

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 foo.c as it existed ten foo.c-changes ago versus ten whole-tree-changes ago:

# 10 foo.c-changes ago
git show $(git rev-list -n 10 --reverse HEAD -- foo.c | head -1):foo.c

# 10 whole-tree-changes ago
git show HEAD~10:foo.c

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.

Storage Efficiency

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 configuration option; or when the user runs git gc or one of the lower-level packing commands), Git will collect many loose objects into a single “pack file”.

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 (pack.depth) and are can be made against any suitable object (pack.window controls how widely Git searches for the best delta base; a version of an historically unrelated file can be used as a base if doing so would yield a good delta compression). The latitude that the depth and window size configurations give the delta compression engine often result in a better delta compression than the CVS-style simple one-version-against-the-next/previous-version “diff” compression.

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

See the How Git Stores Objects and The Packfile sections of The Git Community Book. Also the git pack-objects manpage.

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

share|improve this answer
+1 just for the amount and detail of the information you provided. – Tom Wijsman Jul 7 '10 at 22:04
Also, because Git uses snapshots of files rather than deltas, going back a long way in history is actually easier. Imagine you need to see a file from 20 commits ago. With deltas, you need to undo 20 changesets; with snapshots, you just grab the right snapshot. The longer your history, the bigger the advantage. And if you want to see the diff between the current version and that one, it's just a single diff, rather than having to decide what's been done, undone, redone, etc. – Nathan Long Apr 5 '11 at 11:51
Chris, you seem to have a pretty good handle on Git internals. Any chance you might take a swing at this?… – Nathan Long Apr 5 '11 at 11:52
@ChrisJohnsen Please help me understand this. Based on what you said, can Git get similar (or better) storage efficiency than Subversion? I know that if I commit a file with little changes numerous times, 1GB worth of data can be saved in 100MB. Can Git do the same? – Alireza Noori Feb 12 '13 at 1:55
@AlirezaNoori: It all depends on the nature of the data and the changes captured (size of the file, compressibility of the file, size and location of the changes, etc.). Something like that should certainly be possible (depending on the specifics). In general, Git’s pack files can draw from a larger selection of bases for its delta compression as compared to the strictly reverse-chronological deltas that SVN servers use (used? I do not follow SVN development…). If you have some specific question in mind, you should consider asking a new question that includes all pertinent details. – Chris Johnsen Feb 12 '13 at 5:48

It can be read on the same page:


Consequently, Git does not explicitly record file revision relationships at any level below the source code tree.


It is slightly more expensive to examine the change history of a single file than the whole project. To obtain a history of changes affecting a given file, Git must walk the global history and then determine whether each change modified that file. This method of examining history does, however, let Git produce with equal efficiency a single history showing the changes to an arbitrary set of files. For example, a subdirectory of the source tree plus an associated global header file is a very common case.


Thus you can go back to previous revisions of a file and compare two files.

share|improve this answer

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:

  1. git diff - shows the differences between the last checked in version and files that have been changed, but not had git add run on them.
  2. git diff --cached - shows the differences between the previous version and what all files that have had git add run, but have not been committed
  3. git diff commitid - show the differences between the current working directory and a previous commit as specified with the commitid
  4. git diff commita..commitb - shows the differences between two commits, a and b. The commits could also be symbolic names like branches or tags.
share|improve this answer
This answer is not really correct. All of those commands can be applied to an arbitrary set of files as well as the whole tree - just add the file names at the end... – naught101 Apr 17 '13 at 3:58

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.