Git's object storage already does that, and it is not-negotiable.
Git's object database is snapshot oriented, Individual files are blob
s and directories are tree
objects.
Verify this easily by looking under .git/objects
or doing
git rev-list --objects --all
Now, after a while, for efficiency, the object database will be 'compressed' (known as packing). This results in storage efficiency, but does not involve sotring deltas.
Background
Storing deltas was popularized by RCS, CVS, Subversion and others (SourceSafe?). Mainly, because the model made it easy to transfer changesets because they would already be in delta form. Modern VCS-es (mostly distributed) have evolved away from that, and put the emphasis on data integrity.
Data Integrity
Because of the design of the object database, git is very robust and will detect any corrupted bit of data anywhere in a snapshot, or the entire repo. See this post for more details on the cryptographic properties of Git repositories: Linus talk - Git vs. data corruption?
In techno babble: commit histories form cryptographically strong merkle trees. When the sha1 sum of the tip commit (HEAD) matches, it mathematically follows that
- tree content
- the branch history (including all sign-offs and committer/author credentials)
are identical. This is a huge security feature of git (and other SCMs that share this design feature)