{"thread":{"id":"2559","subject":"git-pack-redundant returns the most containing pack","startedAt":"2005-11-16T23:09:56Z","lastAt":"2005-11-17T20:39:15Z","messageCount":4,"participants":["Alex Riesen","Lukas Sandström"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"12054","messageId":"20051116230956.GA21444@steel.home","threadId":"2559","inReplyTo":null,"subject":"git-pack-redundant returns the most containing pack","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-11-16T23:09:56Z","receivedAt":"2005-11-16T23:09:56Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"...which very confusing: \"git-repack -a -d\" leaves the repository with\nexactly the same packs as before, by creating a super-pack, and then\nhappily removing it, because pack-redundant returns the newly created\npack!\n\nSo, even if it is logically correct, it's hardly useful in practice.\n"},{"id":"12058","messageId":"437BBF5D.5040105@etek.chalmers.se","threadId":"2559","inReplyTo":"20051116230956.GA21444@steel.home","subject":"Re: git-pack-redundant returns the most containing pack","fromName":"Lukas Sandström","fromEmail":"lukass@etek.chalmers.se","sentAt":"2005-11-16T23:23:09Z","receivedAt":"2005-11-16T23:23:09Z","isPatch":false,"sender":{"key":"luksan@gmail.com","avatar":"https://avatars.githubusercontent.com/u/152281?v=4"},"body":"Alex Riesen wrote:\n> ...which very confusing: \"git-repack -a -d\" leaves the repository with\n> exactly the same packs as before, by creating a super-pack, and then\n> happily removing it, because pack-redundant returns the newly created\n> pack!\n> \n> So, even if it is logically correct, it's hardly useful in practice.\n> \n\nThat's bad. Your new pack should contain some objects not present in\nthe older packfiles and thus it shouldn't be removed, unless there\nwere no new objects to pack. \n\nIf no new objects were packed, the sum of the old packs might be smaller \nthan the new superpack, or the old packs could contain unreachable objects,\nwhich makes git-pack-redundant unable to detect that they should be removed.\n\nCould you try updating to the latest snapshot? There was a bug in a\nlist handling function which was fixed recently, perhaps your problem\nis related.\n"},{"id":"12079","messageId":"81b0412b0511162345g1483e7cfia768b18ba3eb1db@mail.gmail.com","threadId":"2559","inReplyTo":"437BBF5D.5040105@etek.chalmers.se","subject":"Re: git-pack-redundant returns the most containing pack","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-11-17T07:45:46Z","receivedAt":"2005-11-17T07:45:46Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 11/17/05, Lukas Sandström <lukass@etek.chalmers.se> wrote:\n> > ...which very confusing: \"git-repack -a -d\" leaves the repository with\n> > exactly the same packs as before, by creating a super-pack, and then\n> > happily removing it, because pack-redundant returns the newly created\n> > pack!\n> >\n> > So, even if it is logically correct, it's hardly useful in practice.\n>\n> That's bad. Your new pack should contain some objects not present in\n> the older packfiles and thus it shouldn't be removed, unless there\n> were no new objects to pack.\n\nthere weren't: \"ls .git/objects\" showed only pack/ and info/\n\n> If no new objects were packed, the sum of the old packs might be smaller\n> than the new superpack, or the old packs could contain unreachable objects,\n> which makes git-pack-redundant unable to detect that they should be removed.\n\nthat _could_ be the case. I run git-fsck-objects --full in that\nrepository and saw some unreferenced tags.\n\n> Could you try updating to the latest snapshot? There was a bug in a\n> list handling function which was fixed recently, perhaps your problem\n> is related.\n\nwill try, but I didn't realize yesterday that it might be a good idea\nto keep the old repository around. The lot of packs was automatically\ncreated by incremental repacking after every pull. Sorry...\n"},{"id":"12141","messageId":"20051117203915.GB3013@steel.home","threadId":"2559","inReplyTo":"81b0412b0511162345g1483e7cfia768b18ba3eb1db@mail.gmail.com","subject":"Re: [PATCH] Make git-pack-redundant non-horribly slow on large sets of packs","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-11-17T20:39:15Z","receivedAt":"2005-11-17T20:39:15Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Lukas Sandström, Thu, Nov 17, 2005 14:11:56 +0100:\n> Change the smallest-set detection algortithm so that when\n> we have found a good set, we don't check any larger sets.\n\nI used latest git (a575603af20a795584d79b32c30bda10fcae5d3f Merge\nbranch 'tojunio' of http://locke.catalyst.net.nz/git/git-martinlanghoff)\nand the patch on top.\n\nAlex Riesen, Thu, Nov 17, 2005 08:45:46 +0100:\n> > Could you try updating to the latest snapshot? There was a bug in a\n> > list handling function which was fixed recently, perhaps your problem\n> > is related.\n> \n> will try, but I didn't realize yesterday that it might be a good idea\n> to keep the old repository around. The lot of packs was automatically\n> created by incremental repacking after every pull. Sorry...\n\nok, pack-redundant --all in a repository with 25 packs completed in\n1.346 sec. That's definitely an improvement.\n\nBut, the repository (a clone of Linus' kernel) didn't have a\nsuperpack. I created one (git repack -a) and started\n\"pack-redundant --all\". And almost oomed the system (it has 1Gb RAM +\n512Mb(historically) swap, BTW): oom-killer killed git-pack-redundant.\nPeak memory usage was around 1.3Gb, than everything stopped. The\nrepository had 140718 objects.\n"}]}