Question about git-prune

I'm wondering why git-prune seems to work differently on the two git repositories I track (Junio's and Linus's).

Specifically, when I use git-prune on Linus's kernel, all the dangling objects disappear completely, and git-fsck shows no objects remaining.

But this is what happens with Junio's repository:

$cd src/git $git-fsck dangling tree c642c018aa55d39fff061183f58062de9d8375ac dangling commit e1341abc3759950e891822088cb0163b71b316b3 dangling commit 9f38e1ef7e7992ca490b9b419f52fb4d11efb0e4 dangling commit b82871b3c32faa8a317007f343fdf2d0ddc9954e $git-prune $git-fsck dangling tree c642c018aa55d39fff061183f58062de9d8375ac dangling commit e1341abc3759950e891822088cb0163b71b316b3 dangling commit 9f38e1ef7e7992ca490b9b419f52fb4d11efb0e4 dangling commit b82871b3c32faa8a317007f343fdf2d0ddc9954e

And here is another puzzle:

$git-fsck --unreachable unreachable commit f291504563a5c96862e600247d233f91572a005f unreachable tree 0e925e128b7b83750e2b8b0d901d7d518cadbdaf unreachable tree c642c018aa55d39fff061183f58062de9d8375ac unreachable tree 0b43ac348827a25d54a6fc90c36c12c4c6bdd6c1 unreachable tree 4d43b9900856904cdfc69769124b1930435dae51 unreachable commit e1341abc3759950e891822088cb0163b71b316b3 unreachable blob 590533321a99bf4d00b872a839527f00616ed593 unreachable tree e355b3845361c5f0c829bd146c47c77867aa36a3 unreachable tree 7e08ac7c56e51ea94db1dd6525c26fe123537b07 unreachable commit 9f38e1ef7e7992ca490b9b419f52fb4d11efb0e4 unreachable commit b82871b3c32faa8a317007f343fdf2d0ddc9954e unreachable commit 750f7b668f33c9e8decbdd8141115328992d6fea

git-prune is supposed to remove all the unreachable objects, IIUC, so it seems that git-prune does nothing at all in Junio's repo.

Can anyone reproduce this behavior, or explain it?

Thanks.

Hi,

On Sat, 30 Jun 2007, walt wrote:

Probably the objects were packed.

I do not understand why you use git-prune directly, to begin with. Why not use git-gc and be done with it?

Hth, Dscho

Johannes Schindelin wrote:

...

I also tried git-prune-packed, which also did nothing AFAICT.

It didn't exist when I started using git. I normally don't use git-prune either, but in this case I was just scanning for problems after switching from cg-update to git-pull.

git-gc did get rid of all the danglers even though git-prune didn't. I'll do some investigating to find out why -- that should get me more up to date with recent changes.

Thanks for your help.

walt <wa1ter@myrealbox.com> writes:

Of course it wouldn't; prune-packed is to prune loose objects that also appear in packs.

What is happening is:

 - You create a pack that has everything reachable from refs at
   one point;

 - You pull or do your own development; the set of objects
   reachable from refs change from the above set.  This set is
   superset of the above only if there is no rewind is
   involved.  Otherwise, some objects already packed in the
   previous step are now unreachable.

 - git-prune and git-prune-packed are about removing loose
   objects.  They never go into existing packs and eradicate
   objects from them.

When you have unreachable cruft in packs, repacking is the only way to rid them ("git repack -a -d", which is run by "git gc").

Hi,

On Sat, 30 Jun 2007, walt wrote:

git-prune-packed prunes objects which are loose _and_ packed.

Fair enough.

The thing you needed was actually git-repack (which is called with every necessary option you need from git-gc).

Basically, your objects were dangling _and_ packed. Thus you had to repack in order to get rid of them, but keep the others.

Ciao, Dscho