Re: [PATCH] gc: ignore old gc.log files

["Philip Oakley" <philipoakley@iee.org>]

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