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

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...
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html