From: Alex Riesen Date: Thu, 17 Nov 2005 07:45:46 GMT Subject: Re: git-pack-redundant returns the most containing pack Message-ID: <81b0412b0511162345g1483e7cfia768b18ba3eb1db@mail.gmail.com> In-Reply-To: <437BBF5D.5040105@etek.chalmers.se> On 11/17/05, Lukas Sandström 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...