codeberg

196 readers

2 users here now

Codeberg is a community-driven, non-profit software development platform operated by Codeberg e.V. and centered around Codeberg.org, a Gitea-based software forge.

founded 11 months ago

How to slim down .git folder? (lemmy.world)

submitted 4 weeks ago by oz1sej@lemmy.world to c/codeberg@programming.dev

7 comments fedilink hide all child comments

I have a repo that I've just uploaded to codeberg. In earlier versions, I had a ton of media files - they have now been removed. However, when I uploaded the repo to codeberg, I'm getting this notification:

Your private repo uses up a large amount of disk storage, while all content should ideally be public and licensed under an OSI- or FSF-approved Free Software licence. Please refer to our ToS and the FAQ about software licenses and private repositories. Thank you for considering to release this repo to the public or reducing your required disk space for this repo.

Turns out, my pushed files are 1 MB, but the .git folder is 279 MB - how do I slim it down?

top 7 comments

sorted by: hot top controversial new old

[–] CameronDev@programming.dev 5 points 4 weeks ago (1 children)

Rewrite history. Use git rebase to squash all commits between adding and removing the blobs. Its gross, and if your project is publically used you need to tell everyone what your doing and why.

[–] oz1sej@lemmy.world 7 points 4 weeks ago (2 children)

Rebase shrunk the .git folder from 280 MB to 267 MB... So in the end, I just deleted the repo AND my local .git folder, created a new repo and uploaded. Now it's 1,5 MB 😁 Thanks!

[–] theit8514@lemmy.world 8 points 4 weeks ago

For the future, git is highly resilient so squashing the commits still leaves all the data in the reflog. After you do that operation a git gc would be needed to remove any unreferenced commits and shrink the git folder.

[–] CameronDev@programming.dev 5 points 4 weeks ago (1 children)

Thats just a very hardcore rebase :D

[–] a_non_monotonic_function@lemmy.world 6 points 4 weeks ago

[–] normalexit@lemmy.world 1 points 4 weeks ago

In the past I've used this: https://rtyley.github.io/bfg-repo-cleaner/

[–] SleeplessCityLights@programming.dev 1 points 4 weeks ago

So git tracks the history of your commits and gives you the ability to restore your project to any exact commit. For text files that is efficiently accomplished by only tracking the delta between text on each commit. For binaries, git can only compare file hashes and if the file changes the whole file is uploaded again in full to your history. You probably changed a few 1mb images a bunch of times and now have every copy of it in your git history. Git LFS solves this problem. You can pull the problematic files out with a tool that rewrites history, but rewriting history is usually not great idea, there are too many footguns.