From: Philip Oakley Date: Thu, 09 Feb 2017 23:57:25 GMT Subject: Re: [PATCH] gc: ignore old gc.log files Message-ID: <1637154470724DABAC99AF6199707A4B@PhilipOakley> In-Reply-To: <20170209032325.bspll66ux6n2pj4n@sigill.intra.peff.net> From: "Jeff King" > On Wed, Feb 08, 2017 at 09:02:22PM -0500, David Turner wrote: > >> The intent of automatic gc is to have a git repository be relatively >> low-maintenance from a server-operator perspective. Of course, large >> operators like GitHub will need a more complicated management strategy, >> but for ordinary usage, git should just work. >> >> In this commit, git learns to ignore gc.log files which are older than >> (by default) one day old. It also learns about a config, gc.maxLogAge >> to manage this. >> >> So git should never get itself into a state where it refuses to do any >> maintenance, just because at some point some piece of the maintenance >> didn't make progress. That might still happen (e.g. because the repo >> is corrupt), but at the very least it won't be because Git is too dumb >> to try again. > > Sounds like a good goal and approach. > >> +gc.maxLogAge:: >> + If the file gc.log exists, then `git gc --auto` won't run >> + unless that file is more than maxLogAge seconds old. Default >> + is 86400, one day. Is there a reason why one day is chosen? If maintenance staff are available 24/7 then a shorter time would be appropriate, but if it's a 5 day work week then they may want longer. Is there a particular case it targets? > > For other time-based config, we use approxidate with a relative time, > like "1 day ago". I think it would make sense for this to match, as it > makes the config a little more readable. > > You can follow the prune_expire example which is right below your new > config variable in all of the hunks of your patch. Though I think > ultimately that isn't parsed inside gc, so you'd eventually look at how > "prune --expire" is handled (which I think is via parse_expiry_date()). > [...] Philip