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

From: Alex Riesen <raa.lkml@gmail.com>
Date: Nov 17, 2005, 07:45 UTC
Message-ID: <81b0412b0511162345g1483e7cfia768b18ba3eb1db@mail.gmail.com>
In-Reply-To: <437BBF5D.5040105@etek.chalmers.se>

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