0

I have a repository in Bitbucket that has ~160MB used, I deleted all branches. The repo is totally clear it continues saying that i have 160 MB used.

Image

How can i real delete all the files in my repo. I dont want to create a new repo.

As adittion. If i add some files , for example "file.mp3" to the repo, then i delete it, it increase the Repo Size and i cannot reduce it again. I tried some post like this Atlassian Help.

Best,

EDIT: Im trying to use BFG. When i made a "bfg --strip-blobs-bigger-than 1M" i got:

Scanning packfile for large blobs: 115
Scanning packfile for large blobs completed in 16 ms.
Found 6 blob ids for large blobs - biggest=47522424 smallest=1515614
Total size (unpacked)=102234236
Found 2 objects to protect
Found 4 commit-pointing refs : HEAD, refs/heads/11.0.0-7, refs/heads/master, refs/notes/master

Protected commits
-----------------

These are your protected commits, and so their contents will NOT be altered:

 * commit 57632224 (protected by 'HEAD')

Cleaning
--------

Found 3 commits
Cleaning commits:       100% (3/3)
Cleaning commits completed in 166 ms.

Updating 1 Ref
--------------

        Ref                   Before     After
        -----------------------------------------
        refs/heads/11.0.0-7 | b333507a | 37b0f5cb

Updating references:    100% (1/1)
...Ref update completed in 16 ms.

Commit Tree-Dirt History
------------------------

        Earliest      Latest
        |                  |
           .     D      .

        D = dirty commits (file tree fixed)
        m = modified commits (commit message or parents changed)
        . = clean commits (no changes to file tree)

                                Before     After
        -------------------------------------------
        First modified commit | b333507a | 37b0f5cb
        Last dirty commit     | b333507a | 37b0f5cb

Deleted files
-------------

        Filename                                 Git id
        -----------------------------------------------------------
        Image.png                             | 6481d63a (3,3 MB)
        Sfile3.rpm                            | e8b6f2b8 (29,4 MB)
        UserManual.pdf                        | 77c29187 (16,2 MB)
        c.res                                 | 92392c06 (1,4 MB)
        xxxx.png                              | 6481d63a (3,3 MB)
        file1                                 | f24d869b (45,3 MB)
        file2                                 | 4e62ab09 (1,9 MB)


In total, 9 object ids were changed.
FrankieGG
  • 21
  • 4

2 Answers2

0

The thing is git stores hashes perpetually, so you have to work a bit harder to remove stuff. By deleting branches, you're really just deleting references to patches stored in the repository.

I recommend you try using bfg. It is very fast and very simple to use.

git clone --mirror git://example.com/some-big-repo.git
java -jar bfg.jar --strip-blobs-bigger-than 100M some-big-repo.git
cd some-big-repo.git
git reflog expire --expire=now --all && git gc --prune=now --aggressive
git push --force

These settings will need to change to suit you needs, but this will actually rewrite the contents of the blobs in the repository.

Verification

To verify these steps, I did the following:

mkdir bfg-test
cd bfg-test
echo "Test bfg cleanup in bitbucket." > README.md
git init
git remote add origin git@bitbucket.org:theherk/bfg-test.git
git add README.md
git commit -m "Initial commit."
git push origin main
# size in bitbucket.org: 57.94 KB
dd if=/dev/urandom bs=1048577 count=1 | base64 > garbage
git add garbage
git checkout -b garbage-branch
git commit -m "Add garbage file."
git push origin garbage-branch
# size in bitbucket.org: 1.12 MB
git checkout main
git branch -D garbage-branch
git push origin -d garbage-branch
# size in bitbucket.org: 1.12 MB
cd ..
git clone --mirror git@bitbucket.org:theherk/bfg-test.git
java -jar ~/bin/bfg.jar --strip-blobs-bigger-than 1K bfg-test.git

At this point, I found no large blobs. If it were there, it would have been stripped. So I checked the size of the repo mirror. 88 KB; as opposed to 1.12 MB reported by bitbucket.org. Turns out, bitbucket did prune the file and the repository actually is smaller, their interface just lies and reports usage including dangling files that will be cleaned up at a later date.

Bottom line, if your clone is smaller, then don't trust the information in your repository settings.

theherk
  • 6,954
  • 3
  • 27
  • 52
  • Hello @theherk, I tried your idea, but its continue saying ~157MB. Also i want to say that i did a "git push --force" instead of "git push --force --tags origin refs/heads/*" because it say "" fatal: options '--mirror' and '--tags' cannot be used together"" . I will add an update to my post with more info. – FrankieGG May 27 '22 at 10:16
  • @FrancoCapraroGG Ah that is probably because of me mixing the actual instructions with my workflow. I updated the answer. Try with `git push --force` instead. – theherk May 27 '22 at 10:30
  • @FrancoCapraroGG Also, I just left the `100M` from the main documentation, you may want to prune much smaller blobs, like `1M` for example. – theherk May 27 '22 at 10:31
  • Hi @theherk , I updated the post, im using 1M because my files are not much bigger but i made "a lot of commits", but it continues saying 160MB of use in Bitbucket . – FrankieGG May 27 '22 at 12:19
  • It says that after you successfully force pushed the mirror to your remote? Or was the push still rejected? You can check the size of the local mirror repository directory using `du`, to see if it worked locally. If it worked locally and the push succeeded then this may be a bug in bitbucket. Bitbucket, I believe, triggers garbage collection on force pushes, so I'm unclear what your issue is. I use this quite often. – theherk May 27 '22 at 13:39
  • @FrancoCapraroGG To verify I created a test repository in bitbucket.org. See my updates on the answer. Basically, bfg is useful, but there is a chance, your repository isn't as big as bitbucket says it is. Check the size of your clone and go from there. – theherk May 27 '22 at 14:38
  • Similar issues reported in many places. [here](https://stackoverflow.com/q/49903193/2081835) for example. You can request they do a `git gc` from their side if you are close to a limit. – theherk May 27 '22 at 14:41
0

Once you add the object to the object DB, it will stay there for at least a while if the object is not pointed by something like a current branch/tag. Even if the object is not pointed by a branch/tag, it can still be held for a while by the reflog which can take a little bit to allow a revision to be cleared up. Git does garbage-collection every so often... and you can force to run it with git gc. Check its options and have fun with it.

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • 2
    I don't know enough about Bitbucket to say whether this is the case for Bitbucket, but it's worth noting that on GitHub, commits *never* go away on their own. GitHub need this to make their fork system work. Bitbucket might use a different system that does not have this same constraint, but they might use a very similar one that does have this same constraint. If so, you must involve the site administrators to actually shrink the storage. – torek May 27 '22 at 11:11
  • @torek's comment is spot-on. What I am saying there applies for _local_ repos. – eftshift0 May 27 '22 at 11:12