Git Maintenance Scheduling on POSIX and Linux Systems

schedule written by `git maintenance start` is similar to this: ----------------------------------------------------------------------- # BEGIN GIT MAINTENANCE SCHEDULE # The following schedule was created by Git # Any edits made in this region might be # replaced in the future by a Git command. 0 1-23 * * * "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=hourly 0 0 * * 1-6 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=daily 0 0 * * 0 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=weekly # END GIT MAINTENANCE SCHEDULE ----------------------------------------------------------------------- The comments are used as a region to mark the schedule as written by Git. Any modifications within this region will be completely deleted by `git maintenance stop` or overwritten by `git maintenance start`. The `crontab` entry specifies the full path of the `git` executable to ensure that the executed `git` command is the same one with which `git maintenance start` was issued independent of `PATH`. If the same user runs `git maintenance start` with multiple Git executables, then only the latest executable is used. These commands use `git for-each-repo --config=maintenance.repo` to run `git maintenance run --schedule=<frequency>` on each repository listed in the multi-valued `maintenance.repo` config option. These are typically loaded from the user-specific global config. The `git maintenance` process then determines which maintenance tasks are configured to run on each repository with each `<frequency>` using the `maintenance.<task>.schedule` config options. These values are loaded from the global or repository config values. If the config values are insufficient to achieve your desired background maintenance schedule, then you can create your own schedule. If you run `crontab -e`, then an editor will load with your user-specific `cron` schedule. In that editor, you can add your own schedule lines. You could start by adapting the default schedule listed earlier, or you could read the crontab(5) documentation for advanced scheduling techniques. Please do use the full path and `--exec-path` techniques from the default schedule to ensure you are executing the correct binaries in your schedule. BACKGROUND MAINTENANCE ON LINUX SYSTEMD SYSTEMS ----------------------------------------------- While Linux supports `cron`, depending on the distribution, `cron` may be an optional package not necessarily installed. On modern Linux distributions, systemd timers are superseding it. If user systemd timers are available, they will be used as a replacement of `cron`. In this case, `git maintenance start` will create user systemd timer units and start the timers. The current list of user-scheduled tasks can be found by running `systemctl --user list-timers`. The timers written by `git maintenance start` are similar to this: ----------------------------------------------------------------------- $ systemctl --user list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Thu 2021-04-29 19:00:00 CEST 42min left Thu 2021-04-29 18:00:11 CEST 17min ago git-maintenance@hourly.timer git-maintenance@hourly.service Fri 2021-04-30 00:00:00 CEST 5h 42min left Thu 2021-04-29 00:00:11 CEST 18h ago git-maintenance@daily.timer git-maintenance@daily.service Mon 2021-05-03 00:00:00 CEST 3 days left Mon 2021-04-26 00:00:11 CEST 3 days ago git-maintenance@weekly.timer git-maintenance@weekly.service ----------------------------------------------------------------------- One timer is registered for each `--schedule=<frequency>` option. The definition of the systemd units can be inspected in the following

The git maintenance command uses cron or systemd timers to schedule background maintenance tasks, and users can customize their own schedules or use the default schedules created by git maintenance start, which ensure that the correct git executable is used and that maintenance tasks are run on each repository listed in the maintenance.repo config option.