0

I have a repository for a client that is 287M. It's about 2 1/2 years old, and that size is not that unusual for the repos I've worked on. What IS unusual is that 181M of that is the .git folder.

There are not an excessive amount of branches and for that matter I have always thought a branch itself doesn't take up that much space, it's just a pointer. But please correct me also if this is wrong.

My questions relate to navigation this (and of course fixing it):

  1. How do I determine which file(s) are responsible for this?
  2. There is a db_dump.sql.gz file that is stupidly included in the repo. How can I remove that file AND remove it from git history entirely as if it never existed? (It's 16M but I'm thinking if an automated process has dumped that file, regularly, and those changes were committed, that might be a part of the reason for the large size).
  3. What are some ways to pare down the size of the git repo if any? Thanks.
Oliver Williams
  • 5,966
  • 7
  • 36
  • 78

1 Answers1

0

You can run git repack to have git recompress its content, but this command should be run once in a while by git anyways.

  1. I know of this post, which gives a script to have git list its objects and size, and then try to give them a human name
  2. This requires rewriting history, so be careful and warn other developers if your repo is shared : the command you are looking for is git filter-branch (with the --index-filter option)

  3. You can run git gc or git repack. Another way is to use a fresh copy of your repo :

    git clone mydir newdir
# see how much disk the new '.git/' dir takes
LeGEC
  • 46,477
  • 5
  • 57
  • 104