From: "Jeff King" <peff@xxxxxxxx>
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