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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Mar 19, 2019, 09:35 UTC
Message-ID: <878sxbdx51.fsf@evledraar.gmail.com>
In-Reply-To: <20190319063904.GC31801@sigill.intra.peff.net>

On Tue, Mar 19 2019, Jeff King wrote:

Show 32 quoted lines

> 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

Show 15 quoted lines

> 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