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

3 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Matt McClure <hidden>
Date: 2016-06-15 22:57:10

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

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

From: Johannes Sixt <hidden>
Date: 2016-06-15 22:57:10

Am 5/8/2013 16:19, schrieb Matt McClure:
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.
[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

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

From: Matt McClure <hidden>
Date: 2016-06-15 22:57:10

On Wed, May 8, 2013 at 10:41 AM, Johannes Sixt [off-list ref] 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help