We have a giant git repository of about 40GB. It contains almost 25 years of development history and was migrated between multiple VCS.
Recently we've been having issues with the repo, so we're looking into reducing the size.
As there are 60 developers actively pushing into the repository, I created a fork to perform test runs of the actions that can reduce repo size.
The first step has been to migrate to git LFS. We have .pdf files in the repo and for a long time have committed .mdb files. The .mdb files are no longer in the repo, but are still in the history.
I've tracked .pdf and .mdb files in LFS:
git lfs track '*.pdf'
git lfs track '*.mdb'
Committed everything:
git commit -a -m 'set up lfs'
Then migrated everything, took about 8-10 hours:
git lfs migrate import --everything
Then I force-pushed everything, which took almost 2 days:
git push --force origin master
And then did some cleanup:
git reflog expire --expire-unreachable=now --all
git gc --prune=now
I also performed housekeeping on the GitLab Server and cloned the repository into a new location afterwards.
But the repo (.git/objects) is still exactly the same size as before, with over 100GB of LFS data on top.
From what I've read, it's normal that the size of the objects stays the same immediately after the migration, but the cleanup should get rid of the files that were migrated.
Is LFS just not useful in our case? Is there anything I am missing for the migration? Any other ideas as to what the reason might be for this?
The next step would be to use filter-repo to try and get rid of some of the size.
If all else fails, we might just set up a new repository from the current working tree and just keep a backup of the history in case we want to look something up...