On Wed, Mar 18, 2015 at 6:27 PM, Jeff King <p...@peff.net> wrote: > > Keeping a file that says "I ran gc at time T, and there were still N > objects left over" is probably the best bet. When the next "gc --auto" > runs, if T is recent enough, subtract N from the estimated number of > objects. I'm not sure of the right value for "recent enough" there, > though. If it is too far back, you will not gc when you could. If it is > too close, then you will end up running gc repeatedly, waiting for those > objects to leave the expiration window. > > I guess leaving a bunch of loose objects around longer than necessary > isn't the end of the world. It wastes space, but it does not actively > make the rest of git slower (whereas having a large number of packs does > impact performance). So you could probably make "recent enough" be "T < > now - gc.pruneExpire / 4" or something. At most we would try to gc 4 > times before dropping unreachable objects, and for the default period, > that's only once every couple days.
We could simply prune unreachables more aggressively, and it would solve this issue at the root cause, no? We do keep things reachable from reflogs, so the only thing you are getting by leaving the unreachables around is for an expert to perform some forensic analysis---especially if there are so many loose objects that are all unreachable, nobody sane can go through them one by one and guess correctly if each of them is what they wished they kept if their ancient reflog entry extended a few weeks more. That is, unless there is some tool to analyse the unreachable loose objects, collect them into meaningful islands, and present them in some way that the end user can make sense of, which I do not think exists (yet). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
