threads / discuss / 5041

Re: git prune pig slow

Subject: Re: git prune pig slow

## tl;dr

2 messages between Jul 29, 2006 and Jul 29, 2006.

replies: 1people: 2as markdown or json

linux@horizon.com· Jul 29, 2006, 22:41 UTC · lore
Show 5 quoted lines
> Btw, another alternative to "git prune" is actually to do
>
>	git repack -a -d
>
> and then just delete all unpacked objects.

No, that's dangerous too. The index file is considered part of the root set for git-fsck-objects, but not for git-repack.

Example script:

$ git-init-db $ cat > hello.c #include <stdio.h>

int
main(void)
{
        puts("Hello, world!");
        return 0;
}
$ git-update-index --add hello.c
$ git-repack -a -d
Generating pack...
Done counting 0 objects.
Nothing new to pack.
$ rm .git/objects/67/159ba959e0a0cd6157bf04d5dad66af59383c2
rm: remove write-protected regular file `.git/objects/67/159ba959e0a0cd6157bf04d5dad66af59383c2'? y
$ git commit
error: invalid object 67159ba959e0a0cd6157bf04d5dad66af59383c2
fatal: git-write-tree: error building trees
Linus Torvalds· Jul 29, 2006, 23:48 UTC · re: linux@horizon.com · lore
On Sat, 29 Jul 2006, linux@horizon.com wrote:
> 
> No, that's dangerous too.  The index file is considered part of the root
> set for git-fsck-objects, but not for git-repack.
Indeed.

Although at least you won't lose any history - at worst you'll have to basically do a "git reset HEAD" to make things right again.

I was careful when I wrote the new git-prune to take the index into account, but I'd forgotten about it wrt the "git repack -a -d" suggestion.

		Linus

← back to recent threads