Reducing repository sizes with filter-repo

Hi all,

As I noticed my repo was getting large, I wanted to use git-filter-repo - GitHub & BitBucket HTML Preview - to reduce its size by deleting some bigger unused folders from the history tree. I followed its documentation, and also Reduce repository size | GitLab - performing a garbage collect by pressing the button in the admin section afterwards - and the results are:

  • The corresponding folders are gone if I clone a fresh dir and inspect the history tree (git filter-repo --analyze)
  • Somehow, the repository size increases instead of decreases! I am talking about the number reported by Gitea on the top right (x commits, x branches, x tags, x MiB).

Before a GC, it increased dramatically after the git push --force. The GC brought it down again, but the total size of the repo has increased compared to before the filter-repo actions.
However, I do notice that cloning a repo means downloading less MBs. I have no idea how this works internally, or if this is related to me using SQLite, and I’d like to know more on how to reduce the repo size.

Thanks much!

Edit: I “fixed” this by creating a new repository on Gitea and pushing my local one to that new remote URL. It reduced the size from 395MiB to 216MiB. Okay… Why?

I have exactly the same problem, however I use MySQL and not SQLite.

Does anybody know a solution to this?

I figured it out. A normal git gc (which is run by Gitea e.g. by cron) does not help
since it’s prune time is only for objects older than 2 weeks.
You have to run
sudo -u git git gc --aggressive --prune=now
in your remote git repository.

Also don’t forget to add proper timeouts on the remote:

  • sudo -u git git config --global pack.windowMemory "100m"
  • sudo -u git git config --global pack.packSizeLimit "100m"
  • sudo -u git git config --global pack.threads "1"

In another case after pushing the reduced repository git pack-objects failed got stuck remotely.