To expand a bit on Kaz Nishimura's correct answer (+1) - Git uses Garbage Collection for automatic memory/storage management, see e.g. Garbage Collecting and esp. git-gc:
Runs a number of housekeeping tasks within the current repository, such as compressing file revisions (to reduce disk space and increase performance) and removing unreachable objects which may have been created from prior invocations of git add.
Users are encouraged to run this task on a regular basis within each repository to maintain good disk space utilization and good operating performance. [emphasis mine]
Some git commands may automatically run git gc; see the --auto flag below for details. [...]
As further outlined in section Configuration, there are various related settings and many default to several days or even months. All these can be changed of course, and in a hosted service like Bitbucket, the emphasized activity of running/configuring appropriate garbage collection is the responsibility of the provider.
How Bitbucket seems to handle this
The possibly resulting size difference you are observing has been subject to many issues in the Bitbucket tracker already - Eric van Zijst explains how/why the Bitbucket schedule for garbage collection is somewhat dynamic in his recent answer to Purge dangling objects in Git:
We originally ran a gc on every push. However that can be expensive for larger repos and so the frequency was tied to several repo properties, including push frequency and size.
Furthermore, we don't run git gc --prune=now and so a gc run does not necessarily remove (all) unreferenced objects. This is necessary as some of Bitbucket's internal processes rely on unreferenced objects having a grace period. [...]
See Eric's answer for details on how to contact support, if this turns out to be an issue in your scenario.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.