"Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > From: Derrick Stolee <dstolee@xxxxxxxxxxxxx> > > A user may want to run certain maintenance tasks based on frequency, not > conditions given in the repository. For example, the user may want to > perform a 'prefetch' task every hour, or 'gc' task every day. To assist, > update the 'git maintenance run --scheduled' command to check the config > for the last run of that task and add a number of seconds. The task > would then run only if the current time is beyond that minimum > timestamp. > > Add a '--scheduled' option to 'git maintenance run' to only run tasks > that have had enough time pass since their last run. This is done for > each enabled task by checking if the current timestamp is at least as > large as the sum of 'maintenance.<task>.lastRun' and > 'maintenance.<task>.schedule' in the Git config. This second value is > new to this commit, storing a number of seconds intended between runs. > > A user could then set up an hourly maintenance run with the following > cron table: > > 0 * * * * git -C <repo> maintenance run --scheduled The scheme has one obvious drawback. An hourly crontab entry means your maintenance.*.schedule that is finer grained than an hour increment will not run as expected. You'd need to take all the schedule intervals and take their GCD to come up with the frequency of the single crontab entry. Wouldn't it make more sense to have N crontab entries for N tasks you want to run periodically, each with their own frequency controlled by crontab? That way, you do not need to maintain maintenance.*.schedule configuration variables and the --scheduled option. It might make maintenance.*.lastrun timestamps unneeded, which would be an added plus to simplify the system quite drastically. Most importantly, that would be the way crontab users are most used to in order to schedule their periodical jobs, so it is one less thing to learn.
