{"thread":{"id":"28643","subject":"Garbage collection creates many unpacked objects.","startedAt":"2011-10-10T23:30:42Z","lastAt":"2011-10-10T23:49:12Z","messageCount":2,"participants":["Martin Fick","Shawn Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"177341","messageId":"201110101730.43302.mfick@codeaurora.org","threadId":"28643","inReplyTo":null,"subject":"Garbage collection creates many unpacked objects.","fromName":"Martin Fick","fromEmail":"mfick@codeaurora.org","sentAt":"2011-10-10T23:30:42Z","receivedAt":"2011-10-10T23:30:42Z","isPatch":false,"sender":{"key":"mfick@codeaurora.org","avatar":null},"body":"If I clone linus' kernel, delete all the tags, and then run \ngit gc, it ends up expanding into about 5K of unpacked \nobjects.  The .git size goes from 473M to 511M.  This seems \na bit strange no?  Shouldn't gcing yield a smaller repo an \nfewer unpacked refs?\n\nIf I do this on our internal kernel repo (which has 2Ktags), \nit gets much more pathological, it expands to about 1M \nobjects and grows to about 7G!!!\n\nThis seems to happen with all versions which I tested, \n1.6.0, 1.7.6 and 1.7.7\n\nAny thoughts?\n\n-Martin\n\n-- \nEmployee of Qualcomm Innovation Center, Inc. which is a \nmember of Code Aurora Forum\n"},{"id":"177343","messageId":"CAJo=hJtGyaudyL63AcaG=y4fvfO8Ka3pn=Orta-imb6AUXO6XA@mail.gmail.com","threadId":"28643","inReplyTo":"201110101730.43302.mfick@codeaurora.org","subject":"Re: Garbage collection creates many unpacked objects.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-10-10T23:49:12Z","receivedAt":"2011-10-10T23:49:12Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Mon, Oct 10, 2011 at 16:30, Martin Fick <mfick@codeaurora.org> wrote:\n> If I clone linus' kernel, delete all the tags, and then run\n> git gc, it ends up expanding into about 5K of unpacked\n> objects.  The .git size goes from 473M to 511M.  This seems\n> a bit strange no?  Shouldn't gcing yield a smaller repo an\n> fewer unpacked refs?\n>\n> If I do this on our internal kernel repo (which has 2Ktags),\n> it gets much more pathological, it expands to about 1M\n> objects and grows to about 7G!!!\n\nThis is caused by unreachable objects being evicted from packs and\nstored as loose objects for up to 2 weeks, until the next `git prune`\nrun. I think you can avoid this by using `git repack -a -d` instead of\n`git gc`, but at the risk that a concurrent modification of the\nrepository may result in corruption due to a race condition between\nthe object being needed, and the object being deleted.\n"}]}