On Fri, Dec 02, 2011 at 09:35:52AM -0800, Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> writes:
>
> > When the objects become unreferenced, we eject them from the pack into
> > loose form again. If they don't become referenced in the 2-week window,
> > they get pruned then. So yes, you drop the age information, but they do
> > eventually go away.
>
> If you update gc/repack -A to put them in a separate pack, then you would
> never be able to get rid of them, no? You pack, then eject (which gives
> them a fresher timestamp), then notice that you are within the 2-week window
> and pack them again,...
But we shouldn't be packing totally unreferenced objects. Barring bugs,
the life cycle of such an object should be something like:
1. Object X is created on branch 'foo'.
2. Branch 'foo' is deleted, but its commits are still in the HEAD
reflog, referencing X.
3. 90 days pass (actually, I think this might be the 30-day
expire-unreachable time)
4. "git gc" runs "git repack -Ad", which will eject X from the pack
into a loose form (because it is not becoming part of the new pack
we are writing).
5. Two weeks pass.
6. "git gc" runs "git prune --expire=2.weeks.ago", which removes the
object.
"gc" runs between (4) and (6) will not re-pack the object, because it
remains unreferenced.
I think things might be slowed somewhat by "gc --auto", which will not
do a "repack -A" until we have too many packs. So steps (3) and (4) are
really more like "gc runs git-repack without -A" 50 times, and then we
finally run "git repack -A".
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html