title: Is it possible to slim a .git repository without rewriting history?
body: <p>We have a number of <code>git</code> repositories which have grown to an unmanageable size due to the historical inclusion of binary test files and java <code>.jar</code> files.</p>
  
  <p>We are just about to go through the exercise of <code>git filter-branch</code>ing these repositories, re-cloning them everywhere they are used (from dozens to hundreds of deployments each, depending on the repo) and given the <a href="https://www.kernel.org/pub/software/scm/git/docs/user-manual.html#problems-With-rewriting-history" rel="noreferrer">problems with rewriting history</a> I was wondering if there might be any other solutions.</p>
  
  <p>Ideally I would like to externalise problem files without rewriting the history of each repository. In theory this should be possible because you are checking out the same files, with the same sizes and the same hashes, just sourcing them from a different place (a remote rather than the local object store). Alas none of the potential solutions I have found so far appear to allow me to do this.</p>
  
  <p>Starting with <a href="http://git-annex.branchable.com/" rel="noreferrer">git-annex</a>, the closest I could find to a solution to my problem was <a href="http://git-annex.branchable.com/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/" rel="noreferrer">How to retroactively annex a file already in a git repo</a>, but as with just removing the large files, this requires the history to be re-written to convert the original <code>git add</code> into a <code>git annex add</code>. </p>
  
  <p>Moving on from there, I started looking at other projects listed on <a href="http://git-annex.branchable.com/not/" rel="noreferrer">what git-annex is not</a>, so I examined <a href="http://caca.zoy.org/wiki/git-bigfiles" rel="noreferrer">git-bigfiles</a>, <a href="https://github.com/schacon/git-media" rel="noreferrer">git-media</a> and <a href="https://github.com/jedbrown/git-fat" rel="noreferrer">git-fat</a>. Unfortunately we can't use the <em>git-bigfiles</em> fork of <code>git</code> since we are an Eclipse <em>shop</em> and use a mixture of <code>git</code> and <a href="http://www.eclipse.org/egit/" rel="noreferrer">EGit</a>. It doesn't look like <em>git-media</em> or <em>git-fat</em> can do what I want either, since while you could replace existing large files with the external equivalents, you would still need to rewrite the history in order to remove large files which had already been committed.</p>
  
  <p>So, is it possible to slim a .git repository without rewriting history, or should we go back to the plan of using <code>git filter-branch</code> and a whole load of redeployments?</p>
  
  <hr>
  
  <p>As an aside, believe that this <em>should</em> be possible, but is probably tied to the same limitations as those of <code>git</code>s current <a href="https://stackoverflow.com/q/6900103/42473">shallow clone</a> implementation. </p>
  
  <p>Git already supports multiple possible locations for the same blob, since any given blob could be in the <a href="http://git-scm.com/book/en/Git-Internals-Git-Objects" rel="noreferrer">loose object store</a> (<code>.git/objects</code>) or in a <a href="http://git-scm.com/book/en/Git-Internals-Packfiles" rel="noreferrer">pack file</a> (.git/objects) so theoretically you would just need something like <code>git-annex</code> to be hooked in at that level rather than higher up (i.e. have the concept of a download on demand <em>remote blob</em> if you like). Unfortunately I can't find anyone having implemented or even suggested anything like this.</p>