views:

2233

answers:

4

We have a git project which has quite a big history.

Specifically, early in the project there were quite a lot of binary resource files in the project, these have now been removed as they're effectively external resources.

However, the size of our repository is >200MB (the total checkout is currently ~20MB) due to having these files previously committed.

What we'd like to do is "collapse" the history so that the repository appears to have been created from a later revision than it was. For example

1-----2-----3-----4-----+---+---+
                   \       /
                    +-----+---+---+
  1. Repository created
  2. Large set of binary files added
  3. Large set of binary files removed
  4. New intended 'start' of repository

So effectively we want to lose the project history before a certain point. At this point there is only one branch, so there's no complication with trying to deal with multiple start points etc. However we don't want to lose all of the history and start a new repository with the current version.

Is this possible, or are we doomed to have a bloated repository forever?

+1  A: 

Is git-fast-export what you are looking for?

NAME
   git-fast-export - Git data exporter

SYNOPSIS
   git-fast-export [options] | git-fast-import

DESCRIPTION
   This program dumps the given revisions in a form suitable to be piped into git-fast-
   import(1).

   You can use it as a human readable bundle replacement (see git-bundle(1)), or as a kind
   of an interactive git-filter-branch(1).
JesperE
+5  A: 

Thanks to JesperE's post I looked into git-filter-branch -- that may actually be what you want. It looks like you could retain your earlier commits too except they would be modified since your Big Files were removed. From the git-filter-branch man page:

Suppose you want to remove a file (containing confidential information or copyright violation) from all commits:

git filter-branch --tree-filter 'rm filename' HEAD

Be sure to read that man page... obviously you'd want to do this on a spare clone of your repository to make sure it works as expected.

Pat Notz
+18  A: 

You can remove the binary bloat and keep the rest of your history. Git allows you to reorder and 'squash' prior commits, so you can combine just the commits that add and remove your big binary files. If the adds were all done in one commit and the removals in another, this will be much easier than dealing with each file.

$ git log --stat       # list all commits and commit messages

Search this for the commits that add and delete your binary files and note their SHA1s, say 2bcdef and 3cdef3.

Then to edit the repo's history, use rebase -i command with its interactive option, starting with the parent of the commit where you added your binaries. It will launch your $EDITOR and you'll see a list of commits starting with 2bcdef:

$ git rebase -i 2bcdef^    # generate a pick list of all commits starting with 2bcdef
# Rebasing zzzzzz onto yyyyyyy 
# 
# Commands: 
#  pick = use commit 
#  edit = use commit, but stop for amending 
#  squash = use commit, but meld into previous commit 
# 
# If you remove a line here THAT COMMIT WILL BE LOST.
#
pick 2bcdef   Add binary files and other edits
pick xxxxxx   Another change
  .
  .
pick 3cdef3   Remove binary files; link to them as external resources
  .
  .

Insert squash 3cdef3 as the second line and remove the line which says pick 3cdef3 from the list. You now have a list of actions for the interactive rebase which will combine the commits which add and delete your binaries into one commit whose diff is just any other changes in those commits. Then it will reapply all of the subsequent commits in order, when you tell it to complete:

$ git rebase --continue

This will take a minute or two.
You now have a repo that no longer has the binaries coming or going. But they will still take up space because, by default, Git keeps changes around for 30 days before they can be garbage-collected, so that you can change your mind. If you want to remove them now:

$ git reflog expire --expire=1.minute refs/heads/master
      #all deletions up to 1 minute  ago available to be garbage-collected
$ git fsck --unreachable      # lists all the blobs(files) that will be garbage-collected
$ git prune
$ git gc

Now you've removed the bloat but kept the rest of your history.

Paul
Good and thourough answer.
JesperE
You just have to remember if others have already pulled from that repository, rewriting history will confuse their pull. The git-rebase manual explains how to recover those other repos. http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
Otto
+2  A: 

You can use git filter-branch with grafts to make the commit number 4 the new root commit of your branch. Just create the file .git/info/grafts with just one line in it containing the SHA1 of commit number 4.

f you now do a git log or gitk you will see that those commands will display commit number 4 as the root of your branch. But nothing will have actually changed in your repository. You can delete .git/info/grafts and the output of git log or gitk will be as before. To actually make commit number 4 the new root you will have to run git filter-branch, with no arguments.

davitenio