Question about git-prune

Question about git-prune

[walt]

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.

Re: Question about git-prune

[Johannes Schindelin]

Hi,

On Sat, 30 Jun 2007, walt wrote:

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

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

Re: Question about git-prune

[walt]

Johannes Schindelin wrote:
> Hi,
> 
> On Sat, 30 Jun 2007, walt wrote:
...
>> $git-prune
>> $git-fsck
>> dangling tree c642c018aa55d39fff061183f58062de9d8375ac
>> dangling commit e1341abc3759950e891822088cb0163b71b316b3
>> dangling commit 9f38e1ef7e7992ca490b9b419f52fb4d11efb0e4
>> dangling commit b82871b3c32faa8a317007f343fdf2d0ddc9954e
> 
> Probably the objects were packed.

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

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

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.

Re: Question about git-prune

[Junio C Hamano]

walt <wa1ter@myrealbox.com> writes:

>> Probably the objects were packed.
>
> I also tried git-prune-packed, which also did nothing AFAICT.

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").

Re: Question about git-prune

[Johannes Schindelin]

Hi,

On Sat, 30 Jun 2007, walt wrote:

> Johannes Schindelin wrote:
> > 
> > On Sat, 30 Jun 2007, walt wrote:
> ...
> > > $git-prune
> > > $git-fsck
> > > dangling tree c642c018aa55d39fff061183f58062de9d8375ac
> > > dangling commit e1341abc3759950e891822088cb0163b71b316b3
> > > dangling commit 9f38e1ef7e7992ca490b9b419f52fb4d11efb0e4
> > > dangling commit b82871b3c32faa8a317007f343fdf2d0ddc9954e
> > 
> > Probably the objects were packed.
> 
> I also tried git-prune-packed, which also did nothing AFAICT.

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

> > I do not understand why you use git-prune directly, to begin with. Why 
> > not use git-gc and be done with it?
> 
> 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.

Fair enough.

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

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