On Thu, Mar 19, 2015 at 8:27 AM, 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.
And would not be hard to implement either. git-gc is already prepared to deal with stale gc.pid, which would stop git-gc for a day or so before it deletes gc.pid and starts anyway. All we need to do is check at the end of git-gc, if we know for sure the next 'gc --auto' is a waste, then leave gc.pid behind. -- Duy -- 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
