threads / discuss / 2559

git-pack-redundant returns the most containing pack

Subject: git-pack-redundant returns the most containing pack

## tl;dr

4 messages between Nov 16, 2005 and Nov 17, 2005.

replies: 3people: 2as markdown or json

Alex Riesen· Nov 16, 2005, 23:09 UTC · lore

...which very confusing: "git-repack -a -d" leaves the repository with exactly the same packs as before, by creating a super-pack, and then happily removing it, because pack-redundant returns the newly created pack!

So, even if it is logically correct, it's hardly useful in practice.

Lukas Sandström· Nov 16, 2005, 23:23 UTC · re: Alex Riesen · lore

Re: git-pack-redundant returns the most containing pack

Alex Riesen wrote:

Show 7 quoted lines

> ...which very confusing: "git-repack -a -d" leaves the repository with
> exactly the same packs as before, by creating a super-pack, and then
> happily removing it, because pack-redundant returns the newly created
> pack!
> 
> So, even if it is logically correct, it's hardly useful in practice.
>

That's bad. Your new pack should contain some objects not present in the older packfiles and thus it shouldn't be removed, unless there were no new objects to pack.

If no new objects were packed, the sum of the old packs might be smaller than the new superpack, or the old packs could contain unreachable objects, which makes git-pack-redundant unable to detect that they should be removed.

Could you try updating to the latest snapshot? There was a bug in a list handling function which was fixed recently, perhaps your problem is related.

Alex Riesen· Nov 17, 2005, 07:45 UTC · re: Lukas Sandström · lore

Re: git-pack-redundant returns the most containing pack

On 11/17/05, Lukas Sandström <lukass@etek.chalmers.se> wrote:

Show 10 quoted lines

> > ...which very confusing: "git-repack -a -d" leaves the repository with
> > exactly the same packs as before, by creating a super-pack, and then
> > happily removing it, because pack-redundant returns the newly created
> > pack!
> >
> > So, even if it is logically correct, it's hardly useful in practice.
>
> That's bad. Your new pack should contain some objects not present in
> the older packfiles and thus it shouldn't be removed, unless there
> were no new objects to pack.

there weren't: "ls .git/objects" showed only pack/ and info/

> If no new objects were packed, the sum of the old packs might be smaller
> than the new superpack, or the old packs could contain unreachable objects,
> which makes git-pack-redundant unable to detect that they should be removed.

that _could_ be the case. I run git-fsck-objects --full in that repository and saw some unreferenced tags.

> Could you try updating to the latest snapshot? There was a bug in a
> list handling function which was fixed recently, perhaps your problem
> is related.

will try, but I didn't realize yesterday that it might be a good idea to keep the old repository around. The lot of packs was automatically created by incremental repacking after every pull. Sorry...

Alex Riesen· Nov 17, 2005, 20:39 UTC · re: Alex Riesen · lore

Re: [PATCH] Make git-pack-redundant non-horribly slow on large sets of packs

Lukas Sandström, Thu, Nov 17, 2005 14:11:56 +0100:

> Change the smallest-set detection algortithm so that when
> we have found a good set, we don't check any larger sets.

I used latest git (a575603af20a795584d79b32c30bda10fcae5d3f Merge branch 'tojunio' of http://locke.catalyst.net.nz/git/git-martinlanghoff) and the patch on top.

Alex Riesen, Thu, Nov 17, 2005 08:45:46 +0100:

Show 7 quoted lines

> > Could you try updating to the latest snapshot? There was a bug in a
> > list handling function which was fixed recently, perhaps your problem
> > is related.
> 
> will try, but I didn't realize yesterday that it might be a good idea
> to keep the old repository around. The lot of packs was automatically
> created by incremental repacking after every pull. Sorry...

ok, pack-redundant --all in a repository with 25 packs completed in 1.346 sec. That's definitely an improvement.

But, the repository (a clone of Linus' kernel) didn't have a superpack. I created one (git repack -a) and started "pack-redundant --all". And almost oomed the system (it has 1Gb RAM + 512Mb(historically) swap, BTW): oom-killer killed git-pack-redundant. Peak memory usage was around 1.3Gb, than everything stopped. The repository had 140718 objects.