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

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

[Robert P. J. Day]

  writing a short tutorial on how to add a remote and work with it
and, as a final step, show how, if one is uninterested in the remote
after all, one can simply delete it, but i also want to show how one
can then prune or garbage collect the objects related to that remote,
but i can't figure out how.

  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.

  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?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                  http://crashcourse.ca/dokuwiki

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

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

[Jeff King]

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

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

[Ævar Arnfjörð Bjarmason]

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

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

[Jeff King]

On Tue, Mar 19, 2019 at 10:35:54AM +0100, Ævar Arnfjörð Bjarmason wrote:

> > 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

Good call. I forgot that we even had --prune-tags.

-Peff