tags:

views:

296

answers:

7

What is the best way for git to consume less disk space?

I'm using git-gc on my repositories but I would like suggestions if there is any other command to shrink the disk space used by git.

Thanks

+2  A: 

Git gc will remove unused objects. That is about everything you can do.

You could consider splitting up your repositories if they become too big.

Sardaukar
+2  A: 

Every git repository contains the entire history. While git does a fairly good job of compressing this stuff, there's simply a lot of data in there.

The "obvious" but potentially not-possible-for-you solution is to start a new repository without all that old history.

Artelius
+3  A: 

git-gc calls lots of other commands that are used to clean up and compress the repository. All you could do is delete some old unused branches.

Short answer: No :-(

Tilka
+1  A: 

You can repack your repository. However i think it's called by git gc

git repack -ad

Rory
+2  A: 

Depending on what you want to do with your repository, you might also consider using the following git clone option:

   --depth <depth>
       Create a shallow clone with a history truncated to the specified
       number of revisions. A shallow repository has a number of
       limitations (you cannot clone or fetch from it, nor push from nor
       into it), but is adequate if you are only interested in the recent
       history of a large project with a long history, and would want to
       send in fixes as patches.
adl
A: 

git prune might be a hint. it cleans the repository from unreachable commits (git gc does not call it)

knittl
From the git-prune manpage: "In most cases, users should run git-gc, which calls git-prune."
mipadi
well, for me my git repositories get smaller by a few mb when calling `git prune` after `git gc` (measured with du -sh .git). maybe `git gc` only prunes older commits, and `git prune` prunes every object which is not reachable
knittl
IIRC `git gc` offers some extra security (not deleting some objects) that `git prune` lacks.
Jakub Narębski
+6  A: 

There are a few suggestions I can offer:

  1. Delete no longer used branches. They can pin some commits that you don't use and would never use. Take care however to not delete branches that you would later need (perhaps for review, or for comparison of failed effort). Backup first.

  2. Check if you didn't commit some large binary file (perhaps some generated file) by mistake. If you have, you can purge it from history using "git filter-branch"... well, if you didn't share the repository, or it is worth aggravating other contributors to rewrite history. Again: backup first.

  3. You can prune more aggressively, discarding some safeties, bu using git gc --prune=now, or low-level git prune. But take care that you don't remove safeties and backups (like reflog) that you need minute after compacting.

  4. Perhaps what enlarges your repository are some untracked files in working directory. There "make clean" or "git clean" might help (but take care that you don't remove some important files).

  5. Most safe of all those suggestions: you can try to pack more aggressively, using --depth and --window option of low-level git-repack. See also Git Repack Parameters blog post by Pieter de Bie on his DVCS Comparison blog, from June 6, 2008. Or "git gc --aggressive".

Jakub Narębski