Take the 2-minute tour ×

My current base has a total size of approx. 200MB.

but my .git folder has an amazing size of 5GB (!). since i push my work to an external server, i don't need any big local history...

how can i shrink the .git folder to free some space on my notebook? Can i delete all changes, that are older, than 30 days?

thanks a lot for any help :)

share|improve this question
Can you post the output of git count-objects -v ? –  Charles Bailey Apr 10 '11 at 17:42

4 Answers 4

up vote 18 down vote accepted

you should not delete all changes older than 30 days (i think it's somehow possible exploiting git, but really not recommended).

you can call git gc --aggressive --prune, which will perform garbage collection in your repository and prune old objects. do you have a lot of binary files (archives, images, executables) which change often? those usually lead to huge .git folders (remember, git stores snapshots for each revision and binary files compress badly)

share|improve this answer
Actually, git gc --aggressive is considered to be bad practice. It's better to use git repack -a -d --depth=250 --window=250. –  Artefact2 Apr 10 '11 at 17:26
@artefact2: is it? git gc call repack internally, so i don't agree with you. do you have a link to back up your claim? –  knittl Apr 10 '11 at 17:38
it's a webproject with lots of php, js, css, and of course images :) i gonna run git gc --aggressive --prue –  JMW Apr 10 '11 at 17:52
@JMW: There's no point in running git gc after running git repack. They do the same job. –  Charles Bailey Apr 10 '11 at 17:54
@knittl: absolutely. Here is a message of Linus himself: gcc.gnu.org/ml/gcc/2007-12/msg00165.html –  Artefact2 Apr 10 '11 at 18:59

From Linus:

The equivalent of "git gc --aggressive" - but done *properly* - is to do (overnight) something like


where that depth thing is just about how deep the delta chains can be (make them longer for old history - it's worth the space overhead), and the window thing is about how big an object window we want each delta candidate to scan.

And here, you might well want to add the "-f" flag (which is the "drop all old deltas", since you now are actually trying to make sure that this one actually finds good candidates.

source: http://gcc.gnu.org/ml/gcc/2007-12/msg00165.html

share|improve this answer

5GB vs 200MB is kind of weird. Try to run git gc.

But no, unless you split your repository into modules, you can't decrease the size of the .git directory.

Each clone of a git repo is a full fledged repository that can act as a server. That's the base principle of distributed version control.

share|improve this answer

I'm using git more as synchronization mechanism than for version history. So my solution to this problem has been to make sure I have all my current sources in a satisfactory state, and then just delete .git and re-initialize the repos. Disk space problem solved. :-) History gone :-( I do this because my repo is on a small USB key. I don't want or need my entire history. If I had a method for just truncating the history, I would use that.

If I were interested in keeping my history I would archive the current repository. At some point later I could clone the original repository, copy over all the changes from the new repo (let's assume I haven't done much (any) renaming or deleteing). And then make one big commit that would represent all the changes made in the new repo as a single commit in the old repo. Is it possible to merge the histories? Maybe if I used a branch and then deleted the objects I didn't need. (I dont' know enough about git internals to start fooling around like that).

share|improve this answer

Your Answer


