threads / discuss / 33752

`git prune` doc or implementation defect, or user misunderstanding

Subject: `git prune` doc or implementation defect, or user misunderstanding

## tl;dr

3 messages between May 8, 2013 and May 8, 2013.

replies: 2people: 2as markdown or json

Matt McClure· May 8, 2013, 14:19 UTC · lore
The `git prune` documentation says:
       This runs git fsck --unreachable using all the refs
       available in refs/, optionally with additional set of
       objects specified on the command line, and prunes all
       unpacked objects unreachable from any of these head
       objects from the object database. In addition, it prunes
       the unpacked objects that are also found in packs by
       running git prune-packed.
       Note that unreachable, packed objects will remain. If this
       is not desired, see git-repack(1).

My interpretation of that is that `git prune` will not prune packed objects by default. The following behavior seems inconsistent with that interpretation.

[git@438587-beefcake01 panama.git]$ git prune -n | wc -l 9210 [git@438587-beefcake01 panama.git]$ git fsck --unreachable | wc -l 9468 [git@438587-beefcake01 panama.git]$ git gc --no-prune Counting objects: 531223, done. Delta compression using up to 24 threads. Compressing objects: 100% (109848/109848), done. Writing objects: 100% (531223/531223), done. Total 531223 (delta 405288), reused 530894 (delta 404961) [git@438587-beefcake01 panama.git]$ git prune -n | wc -l 9468 [git@438587-beefcake01 panama.git]$ git fsck --unreachable | wc -l 9468

It looks like `git prune -n` is telling me that it would prune the objects that I just packed. What am I misunderstanding?

-- Matt McClure http://matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure

Johannes Sixt· May 8, 2013, 14:41 UTC · re: Matt McClure · lore

Re: `git prune` doc or implementation defect, or user misunderstanding

Am 5/8/2013 16:19, schrieb Matt McClure:
Show 6 quoted lines
> My interpretation of that is that `git prune` will not prune packed objects
> by default. The following behavior seems inconsistent with that
> interpretation.
> 
> [git@438587-beefcake01 panama.git]$ git prune -n | wc -l
> 9210
You have 9210 unreachable, loose objects.
> [git@438587-beefcake01 panama.git]$ git fsck --unreachable | wc -l
> 9468
You have 9468 unreachable objects in total.
Show 6 quoted lines
> [git@438587-beefcake01 panama.git]$ git gc --no-prune
> Counting objects: 531223, done.
> Delta compression using up to 24 threads.
> Compressing objects: 100% (109848/109848), done.
> Writing objects: 100% (531223/531223), done.
> Total 531223 (delta 405288), reused 530894 (delta 404961)

Only reachable objects go into the new pack. Unreachable objects that were in the pack before, are evicted and are now loose.

> [git@438587-beefcake01 panama.git]$ git prune -n | wc -l
> 9468
> [git@438587-beefcake01 panama.git]$ git fsck --unreachable | wc -l
> 9468
Now all 9468 unreachable objects are loose and eligible for being pruned.
> It looks like `git prune -n` is telling me that it would prune the objects
> that I just packed. What am I misunderstanding?

git gc moves unreachable objects that were packed before to the loose object store, from where they can be pruned.

-- Hannes
Matt McClure· May 8, 2013, 16:05 UTC · re: Johannes Sixt · lore

Re: `git prune` doc or implementation defect, or user misunderstanding

On Wed, May 8, 2013 at 10:41 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> git gc moves unreachable objects that were packed before to the loose
> object store, from where they can be pruned.
Thanks. That was the piece I was missing. I assumed `git gc` did the opposite.
-- 
Matt McClure
http://matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure

← back to recent threads