0

Since my repository size in bitbucket increased to 1GB over time, I would like to cut it and delete old history that I do not care about anymore.

I expect to cut my repository to atleast size of up to 100 mb (or atleast half of current) and have a history of 3-5 months. That means I'm OK to have less commits in my history.

This is what I have already tried and it did not work:

  1. running git gc (with flags like --aggressive --prune). It did decrease my repo size to approximately 400mb locally. But I could not push it to remote, and therefore my BitBucket's repo size stayed the same. I tried using this method for Bitbucket garbage collection cleaning: https://stackoverflow.com/a/27868384/8610581 as well as https://stackoverflow.com/a/37253227/8610581
  2. I tried shallow clone (git clone --shallow-since=<date> and also with --depth) which does exactly what I need. Unfortunately, I can not make a new repository out of the shallow clone (git does not allow that).
  3. I tried reducing size of my repo by squashing many old commits into one. I did manage to get less commits in my repo, but it did not affect my repository's size (.git folder in particular) and it remained the same.
  4. Deleted unused and merged branches
Juozas Rastenis
  • 265
  • 3
  • 9

2 Answers2

0

The only way to delete history in Git (while keeping the latest commits) is to replace the repository.

The replacement repository could have the same name as the original repository, but it will have a completely different set of commits. The reason is that each commit is numbered (using a hash ID), and the numbering scheme incorporates the number of the previous commit. So if there were, say, 1000 commits total in the old repository, and there are now only 500 commits in the new one, the commit number of the first commit in the new repository is different, which means the commit number of the final commit in the new repository is different too.

To copy some of the old commits, and/or drop large files in the process, from the old repository to a new repository, there are a number of tools available. The one that is included with Git is git filter-branch, which is in the process of being replaced by git filter-repo (but filter-repo is not yet included in Git itself). You can also use The BFG.

Note that these tools generally work by this process:

  1. Clone the original repository. (Now if you damage the clone irretrievably, you just throw it away and start over!)

  2. Use the tool on the clone. This rewrites the repository in place.

  3. Check to see if the result is good. If not, throw this clone away and go back to step 1.

  4. If necessary (e.g., git filter-branch) perform some finalization steps (with git filter-branch the finalization is to remove refs/original/ or clone this clone; see the documentation).

Remember that the final result is, in effect, an all-new repository. If you allow Git to merge it with the old repository, you'll get all the old commits—the ones you wanted to get rid of—back, and now have two copies of the commits you wanted to keep.

torek
  • 448,244
  • 59
  • 642
  • 775
0

git gc only removes entries from the Git history that are no longer referenced. To get rid of unnecessary history entries in your repo, you have to do the cleanup in this order:

  1. squash old commits on your master branch: This removes references to old entries but keeps the old entries around in your .git folder.
  2. run git gc and git prune: this removes the old entries which are no longer referenced by your new shorter Git history from your local .git folder
  3. push the new smaller Git history to BitBucket: git push --force. Since the history is different, BitBucket refuses normal pushes and you have to use --force to overwrite the history on the server.
  4. All other computers that also have your repo checked out, for example your CI server, are now out of sync. To get them back in sync, run git reset --hard origin/master or whatever your main development branch is.
  5. Rebase all open feature branches against the new master branch so that you don't get the old history back when you merge them.
Kevin Goslar
  • 357
  • 3
  • 8