# git-pack-redundant returns the most containing pack

4 messages from 2005-11-16 to 2005-11-17. Participants: Alex Riesen, Lukas Sandström.
Thread: https://gitlist.dev/t/2559

## Alex Riesen, 2005-11-16 23:09

Subject: git-pack-redundant returns the most containing pack
Message-ID: <20051116230956.GA21444@steel.home>
URL: https://gitlist.dev/e/20051116230956.GA21444%40steel.home

```
...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, 2005-11-16 23:23

Subject: Re: git-pack-redundant returns the most containing pack
Message-ID: <437BBF5D.5040105@etek.chalmers.se>
URL: https://gitlist.dev/e/437BBF5D.5040105%40etek.chalmers.se
In-Reply-To: <20051116230956.GA21444@steel.home>

```
Alex Riesen wrote:
> ...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, 2005-11-17 07:45

Subject: Re: git-pack-redundant returns the most containing pack
Message-ID: <81b0412b0511162345g1483e7cfia768b18ba3eb1db@mail.gmail.com>
URL: https://gitlist.dev/e/81b0412b0511162345g1483e7cfia768b18ba3eb1db%40mail.gmail.com
In-Reply-To: <437BBF5D.5040105@etek.chalmers.se>

```
On 11/17/05, Lukas Sandström <lukass@etek.chalmers.se> wrote:
> > ...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, 2005-11-17 20:39

Subject: Re: [PATCH] Make git-pack-redundant non-horribly slow on large sets of packs
Message-ID: <20051117203915.GB3013@steel.home>
URL: https://gitlist.dev/e/20051117203915.GB3013%40steel.home
In-Reply-To: <81b0412b0511162345g1483e7cfia768b18ba3eb1db@mail.gmail.com>

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

```