Re: how can i "gc" or "prune" objects related to a deleted remote?

[Jeff King <peff@peff.net>]

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

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