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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]