On Thu, Mar 19, 2015 at 11:29:57AM +0700, Duy Nguyen wrote: > > That omits the "N objects left over" information. Which I think may be > > useful, because otherwise the rule is basically "don't do another gc at > > all for X time units". That's OK for most use, but it has its own corner > > cases. > > True. But saving "N objects left over" in a file also has a corner > case. If the user "prune --expire=now" manually, the next 'gc --auto' > still thinks we have that many leftovers and keeps delaying gc for > some more time. Unless we make 'prune' (or any other commands that > delete leftovers) to also delete this file. Yeah maybe saving this > info in a file will work.
I assumed that the user would not run prune manually, but would run "git gc --prune=now". And yeah, definitely any time gc runs, it should update the file (if there are fewer than `gc.auto` objects, I think it could just delete the file). We could also apply that rule any run of "git prune", but my mental model is that "git gc" is the magical porcelain that will do this stuff for you, and "git prune" is the plumbing that users shouldn't need to call themselves. I don't know if that model is shared by users, though. :) -Peff -- 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
