{"thread":{"id":"57844","subject":"2.36.0: enormous numbers of loose objects after enabling partial clone filter: why? how to clean up?","startedAt":"2022-05-04T21:25:08Z","lastAt":"2022-05-04T21:25:08Z","messageCount":1,"participants":["Nix"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"454838","messageId":"877d71cadr.fsf@esperi.org.uk","threadId":"57844","inReplyTo":null,"subject":"2.36.0: enormous numbers of loose objects after enabling partial clone filter: why? how to clean up?","fromName":"Nix","fromEmail":"nix@esperi.org.uk","sentAt":"2022-05-04T20:26:24Z","receivedAt":"2022-05-04T21:25:08Z","isPatch":false,"sender":{"key":"nix@esperi.org.uk","avatar":"https://avatars.githubusercontent.com/u/6503005?v=4"},"body":"So I turned on promisor remotes for my local Chromium tree last week:\nthe relevant remote now has partialclonefilter = blob:limit=10m. I\nwanted to save a bit of space (well, OK, I was hoping for a lot).\n\nThis turned out to be... a bad idea. The first fetch after that exploded\nsome 45GiB of loose objects (nearly six million of them). I spotted an\nancient historical config option gc.pruneExpire=never and removed it:\nthat would explain the worst of the accumulation, if the files weren't\nall dated at around the time of my first pull after turning on partial\nclone.\n\nA git repack -ad, git prune --expire=now, and similar expiry of all the\nreflogs has got them down to a mere 112957 objects, 597304 kilobytes (!)\nbut I can't get the count lower than that, despite deleting every remote\n(to get rid of the remote-tracking branches) and doing a full repack\n(non-aggressive), prune, and a git prune-packed (which had no effect at\nall). I've done not a great deal of work in this tree and no rebases:\nthere should be hardly any legitimate loose objects, I'd have thought.\n\nIndeed, git fsck --verbose --name-objects shows that all these objects\nare referenced, mostly in a few fairly recent branches. They also\nclearly reside upstream, in the remote-tracking branches. So... why is\ngit repack refusing to pack them? Is there any way to find out? It's\nfairly opaque in its decisions, which usually I don't worry about, but\nthis space bloat is kind of ridiculous.\n\n(There are no alternates or anything like that pointing at this repo, so\nit's not that.)\n\n-- \nNULL && (void)\n"}]}