On Tue, Mar 19 2019, Jeff King wrote:
> On Fri, Mar 08, 2019 at 10:36:44AM -0500, Robert P. J. Day wrote:
>
>> as an example, i cloned the linux kernel source tree, then added
>> the linux-next repo as a remote -- the end result was two pack files
>> (the smaller one i'm assuming being for linux-next):
>>
>> $ ls -l .git/objects/pack
>> total 2723632
>> -r--r--r--. 1 rpjday rpjday 1215376 Mar 8 09:44
>> pack-08cc266c0914e924961a1c8412fdf8746d327d7e.idx
>> -r--r--r--. 1 rpjday rpjday 38402840 Mar 8 09:44
>> pack-08cc266c0914e924961a1c8412fdf8746d327d7e.pack
>> -r--r--r--. 1 rpjday rpjday 204032716 Mar 8 09:42
>> pack-1036510bb74967c91093fc0cd8982683a66dbf5f.idx
>> -r--r--r--. 1 rpjday rpjday 2545333327 Mar 8 09:42
>> pack-1036510bb74967c91093fc0cd8982683a66dbf5f.pac
>> $
>>
>> after playing with a couple branches from the new remote, i deleted
>> the remote, then also did things like clear the reflog, delete any
>> local tracking branches related to the deleted remote, and so on, but
>> i can't seem to prune the objects that should no longer be reachable
>> now that i deleted that remote.
>
> After arriving at a similar state, I did:
>
> git remote rm linux-next
> git tag -d next-20190319
> git gc --prune=now
>
> My guess is you forgot the tag? There's not a general solution there,
> because the tags all get intermingled. Git has no idea which ones came
> from which remote. However, if you have the commit id of an object you
> expect to be going away, you can use:
>
> git for-each-ref --contains=$that_commit
Not a general solution, but if you know you have one remote left, and
you don't have unpushed locally created tags, you can do a:
git fetch origin --prune --prune-tags
> to see what's still pointing to it (even indirectly).
>
> Expiring the HEAD reflog is another frequently-forgotten thing, but in
> my case I had never actually checked out any branches. You should be
> able to do "git reflog expire --expire-unreachable=now --all" for that.
>
>> what am i overlooking? is it because those objects are in a separate
>> pack file? do i need to repack first? what is hanging onto those
>> objects in that second pack file such that they can't be garbage
>> collected?
>
> The two packs shouldn't matter. The gc process works by repacking what's
> reachable, not including what's not, and then deleting the old packs.
>
> -Peff
