1

I have git repo with android app and It looks like one of developers didn't gitignore correctly so .apk files were committed and repo became huge (repo is ~300Mb, app size is ~30Mb).

I deleted some garbage:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch ./app/release/app-release.apk' --tag-name-filter cat -- --all

git filter-branch --index-filter 'git rm --cached --ignore-unmatch ./app/build/outputs/apk/debug/app-debug.apk' --tag-name-filter cat -- --all

Repo size became smaller, it's 200Mb now, but when I'm searching for big commits:

git verify-pack -v .git/objects/pack/pack-*.idx | sort -k 3 -n | tail -20

I still see commits which contain .apk files, but I can't even checkout those commits: enter image description here

So the question is how can I shrink that pack file?

kagarlickij
  • 7,327
  • 10
  • 36
  • 71
  • Complete side-question, if that screenshot is from macOS terminal, how did you get that specific prompt there? I've been trying to get something better than the just basic branch information and would really love to have that branch icon and so on as well. – Lasse V. Karlsen Jan 09 '18 at 07:30
  • If you dont need that file, I assume you do not need the .apk file, why not delete it entirely? – ICanKindOfCode Jan 09 '18 at 07:30
  • 1
    Try `git repack -A` followed by `git gc --aggressive --prune`, followed by another `git repack -A`, see if that helps. – Lasse V. Karlsen Jan 09 '18 at 07:31
  • The .apk file is not a commit, and not even a tree, it's just a file (blob). You need to find, or at least just get rid of, the commit(s) that contain that blob, and what name(s) make those commits reachable. If they're retained by reflogs or `refs/original/` references, they won't be garbage collected until that's no longer the case. – torek Jan 09 '18 at 07:55
  • Lasse Vågsæther Karlsen after git repack -A, git gc --aggressive --prune, git repack -A size has been reduced from 213Mb to 198Mb so it's still huge – kagarlickij Jan 09 '18 at 08:09
  • @Lasse Vågsæther Karlsen you could use this gude to make your terminal nice - https://gist.github.com/kevin-smets/8568070 – kagarlickij Jan 09 '18 at 08:10
  • @torek so how could I remove those blobs from all commits? – kagarlickij Jan 09 '18 at 08:12
  • You can't *remove* them from commits. You can *copy* existing commits to new, different commits that are pretty similar to the originals, but lack the large blobs. That's what your `git filter-branch` commands do. Then you stop *using* the old commits—that's the part you haven't achieved, yet: *something* is still using the old commits. `git gc` can't remove them until *nothing* is using them. Find what's using them (reflogs and/or `refs/original/` references for instance) and remove those references, provided you're sure the to-be-kept data are safely copied. – torek Jan 09 '18 at 08:15
  • Possible duplicate of [Remove large .pack file created by git](https://stackoverflow.com/questions/11050265/remove-large-pack-file-created-by-git) – phd Jan 09 '18 at 10:05
  • @kagarlickij Thanks! Will try it out tonight! – Lasse V. Karlsen Jan 09 '18 at 11:03
  • probably you should force expiration as described [here](https://stackoverflow.com/questions/11050265/remove-large-pack-file-created-by-git#comment80426899_11277929). If that fails you need to find somehow which commits still refer to the blob, and are there references which prevent the commits from beibg collected – max630 Jan 09 '18 at 16:30
  • @LasseVågsætherKarlsen I had the same issue (with [SecLists](https://github.com/danielmiessler/SecLists)). Results (.git dir size, MB): after `repack`: 1017; after `gc`: 446; after 2nd `repack`: 892. For some reason, the 2nd `repack` created a copy of a pack object (446 MB) that's `diff`-identical . Any ideas? – Sai Mar 04 '19 at 11:25
  • Ran `git repack -Ad` and it's back to 446. – Sai Mar 04 '19 at 11:32

0 Answers0