Is the git storage model wasteful?

I was reading about how git stores changes here.

It sounds like if I change one line in a file, it’s going to re-store the entire file. Does this waste a lot of space compared to say, Subversion which only stores diffs?

(Or am I misunderstanding the storage model?)

  • Recursively ignoring files in the entire source tree in subversion
  • Ignore files committed to git and also remove them from history
  • After git merge, This branch is 1 commit behind
  • Local commits pushing to a central server
  • Where should you store 3rd party assemblies?
  • Uncommited changes persist in checkout, generate no warnings
  • Fatal: ambiguous argument '<branch_name>': both revision and filename
  • Is there a way to merge the commit history from an SVN repository to a Git branch?
  • 3 Solutions collect form web for “Is the git storage model wasteful?”

    Git will eventually pack everything into delta-compressed archives during the regular course of its internal maintenance, at which point this is no longer an issue.

    This isn’t really an issue today though. Git’s philosophy is that disk space is cheap, and it’s better optimize for speed rather than storage efficiency. Chances are you’ll be better served by a SCM which is twice as fast, as opposed to one which requires half the disk space.

    See the Git Book’s chapter on The Packfile as well as git repack and git-pack-objects.

    Git does compress stored files with with zlib and it also packs them for a more efficient storage.

    Actually not. There is a good article describing the advantage of git:

    Git Baby is a git and github fan, let's start git clone.