title: Fixing up a git repo that is slowed because of big binary files
body: <p>We have a git repo containing both source code and binaries. The bare repo has now reached ~9GB, and cloning it takes ages. Most of the time is spent in "remote: Compressing objects". After a commit with a new version of one of the bigger binaries, a fetch takes a long time, also spent compressing objects on the server.</p>
  
  <p>After reading <a href="https://stackoverflow.com/questions/7102053/git-pull-without-remotely-compressing-objects">git pull without remotely compressing objects</a> I suspect delta compression of binary files is what hurts us as well, but I'm not 100% sure how to go about fixing this.</p>
  
  <p>What are the exact steps to fix the bare repo on the server? My guess:</p>
  
  <ul>
  <li>Add entries like '*.zip -delta' for all extensions I want to into .git/info/attributes</li>
  <li>Run 'git repack', but with what options? Would -adF repack everything, and leave me with a repo where no delta compression has ever been done on the specified file types?</li>
  <li>Run 'git prune'. I thought this was done automatically, but running it when I played around with a bare clone of said repo decreased the size by ~2GB</li>
  <li>Clone the repo, add and commit a .gitattributes with the same entries as I added in .git/info/attributes on the bare repo</li>
  </ul>
  
  <p>Am I on to something?</p>
  
  <p><strong>Update:</strong></p>
  
  <p>Some interesting test results on this. Today I started a bare clone of the problematic repo. Our not-so-powerful-server with 4GB ram ran out of memory and started swapping. After 3 hours I gave up...</p>
  
  <p>Then I instead cloned a bare repo from my up-to-date working copy. Cloning that one between workstations took ~5 minutes. I then pushed it up to the server as a new repo. Cloning <em>that</em> repo took only 7 minutes.</p>
  
  <p>If I interpret this correctly, a better packed repo performs much better, even without disabling the delta-compression for binary files. I guess this means the steps above are indeed what I want to do in the short term, but in addition I need to find out how to limit the amount of memory git is allowed to use for packing/compression on the server so I can avoid the swapping.</p>
  
  <p>In case it matters: The server runs git 1.7.0.4 and the workstations run 1.7.9.5.</p>
  
  <p><strong>Update 2:</strong></p>
  
  <p>I did the following steps on my testrepo, and think I will chance to do them on the server (after a backup)</p>
  
  <ul>
  <li><p>Limit memory usage when packing objects</p>
  
  <p><em>git config pack.windowMemory 100m</em><br>
  <em>git config pack.packSizeLimit 200m</em></p></li>
  <li><p>Disable delta compression for some extensions</p>
  
  <p><em>echo '*.tar.gz -delta' >> info/attributes</em><br>
  <em>echo '*.tar.bz2 -delta' >> info/attributes</em><br>
  <em>echo '*.bin -delta' >> info/attributes</em><br>
  <em>echo '*.png -delta' >> info/attributes</em></p></li>
  <li><p>Repack repository and collect garbage</p>
  
  <p><em>git repack -a -d -F --window-memory 100m --max-pack-size 200m</em><br>
  <em>git gc</em></p></li>
  </ul>
  
  <p><strong>Update 3:</strong></p>
  
  <p>Some unexpected side effects after this operation: <a href="https://stackoverflow.com/questions/13367431/issues-after-trying-to-repack-a-git-repo-for-improved-performance">Issues after trying to repack a git repo for improved performance</a></p>