Git's repack --drop-filtered reclaims the disk a partial clone quietly took back

Git's repack --drop-filtered option reclaims disk space from partial clones that took back space due to lazily fetched objects. This feature, merged on August 25, 2026, is not yet available in version 2.55.0, but is slated for inclusion in version 2.56. A test was conducted on a synthetic repository with 61 commits, twelve 3 MiB assets, and two rewritten assets in every commit.

The clone resulted in a 36 MiB .git directory, with the remaining 324 MiB representing the history. Various operations such as git gc, git rev-list, and git fsck were performed on the clone, revealing that they did not reclaim any disk space. However, when the repack --drop-filtered option was applied, 120 blobs were eliminated, reducing the .git directory to 372 KiB.

The command proved to be nearly instant, taking only 36 milliseconds to complete. Despite the promising results, a limitation was encountered when using the option with a large file in the working tree or index, causing the repack to fail. This limitation prevents the option from being useful in cases where large files are present, rendering it ineffective for common scenarios such as large monorepo setups.

A workaround suggested was to maintain a separate branch without the large directories and use it for repacking, but this is deemed impractical for a general suggestion. The time and disk space saved by using repack --drop-filtered were demonstrated through comparisons between repacks with and without the option. The former took significantly less time (0.94–0.97 seconds) and pulled only the necessary data locally (0 MiB), while the latter pulled 1,801 MiB over a file:// transport.

Ultimately, the cost of retrieving dropped blobs again through future git fetches highlights the importance and efficiency of utilizing the repack --drop-filtered option.