If I clone linus' kernel, delete all the tags, and then run
git gc, it ends up expanding into about 5K of unpacked
objects. The .git size goes from 473M to 511M. This seems
a bit strange no? Shouldn't gcing yield a smaller repo an
fewer unpacked refs?
If I do this on our internal kernel repo (which has 2Ktags),
it gets much more pathological, it expands to about 1M
objects and grows to about 7G!!!
This seems to happen with all versions which I tested,
1.6.0, 1.7.6 and 1.7.7
Any thoughts?
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
On Mon, Oct 10, 2011 at 16:30, Martin Fick [off-list ref] wrote:
If I clone linus' kernel, delete all the tags, and then run
git gc, it ends up expanding into about 5K of unpacked
objects. The .git size goes from 473M to 511M. This seems
a bit strange no? Shouldn't gcing yield a smaller repo an
fewer unpacked refs?
If I do this on our internal kernel repo (which has 2Ktags),
it gets much more pathological, it expands to about 1M
objects and grows to about 7G!!!
This is caused by unreachable objects being evicted from packs and
stored as loose objects for up to 2 weeks, until the next `git prune`
run. I think you can avoid this by using `git repack -a -d` instead of
`git gc`, but at the risk that a concurrent modification of the
repository may result in corruption due to a race condition between
the object being needed, and the object being deleted.