@@ -29,13 +29,55 @@ Git repository.
2929SUBCOMMANDS
3030-----------
3131
32+ register::
33+ Initialize Git config values so any scheduled maintenance will
34+ start running on this repository. This adds the repository to the
35+ `maintenance.repo` config variable in the current user's global
36+ config and enables some recommended configuration values for
37+ `maintenance.<task>.schedule`. The tasks that are enabled are safe
38+ for running in the background without disrupting foreground
39+ processes.
40+ +
41+ The `register` subcomand will also set the `maintenance.strategy` config
42+ value to `incremental`, if this value is not previously set. The
43+ `incremental` strategy uses the following schedule for each maintenance
44+ task:
45+ +
46+ --
47+ * `gc`: disabled.
48+ * `commit-graph`: hourly.
49+ * `prefetch`: hourly.
50+ * `loose-objects`: daily.
51+ * `incremental-repack`: daily.
52+ --
53+ +
54+ `git maintenance register` will also disable foreground maintenance by
55+ setting `maintenance.auto = false` in the current repository. This config
56+ setting will remain after a `git maintenance unregister` command.
57+
3258run::
3359 Run one or more maintenance tasks. If one or more `--task` options
3460 are specified, then those tasks are run in that order. Otherwise,
3561 the tasks are determined by which `maintenance.<task>.enabled`
3662 config options are true. By default, only `maintenance.gc.enabled`
3763 is true.
3864
65+ start::
66+ Start running maintenance on the current repository. This performs
67+ the same config updates as the `register` subcommand, then updates
68+ the background scheduler to run `git maintenance run --scheduled`
69+ on an hourly basis.
70+
71+ stop::
72+ Halt the background maintenance schedule. The current repository
73+ is not removed from the list of maintained repositories, in case
74+ the background maintenance is restarted later.
75+
76+ unregister::
77+ Remove the current repository from background maintenance. This
78+ only removes the repository from the configured list. It does not
79+ stop the background maintenance processes from running.
80+
3981TASKS
4082-----
4183
@@ -110,7 +152,18 @@ OPTIONS
110152 only if certain thresholds are met. For example, the `gc` task
111153 runs when the number of loose objects exceeds the number stored
112154 in the `gc.auto` config setting, or when the number of pack-files
113- exceeds the `gc.autoPackLimit` config setting.
155+ exceeds the `gc.autoPackLimit` config setting. Not compatible with
156+ the `--schedule` option.
157+
158+ --schedule::
159+ When combined with the `run` subcommand, run maintenance tasks
160+ only if certain time conditions are met, as specified by the
161+ `maintenance.<task>.schedule` config value for each `<task>`.
162+ This config value specifies a number of seconds since the last
163+ time that task ran, according to the `maintenance.<task>.lastRun`
164+ config value. The tasks that are tested are those provided by
165+ the `--task=<task>` option(s) or those with
166+ `maintenance.<task>.enabled` set to true.
114167
115168--quiet::
116169 Do not report progress or other information over `stderr`.
@@ -122,6 +175,50 @@ OPTIONS
122175 `maintenance.<task>.enabled` configured as `true` are considered.
123176 See the 'TASKS' section for the list of accepted `<task>` values.
124177
178+
179+ TROUBLESHOOTING
180+ ---------------
181+ The `git maintenance` command is designed to simplify the repository
182+ maintenance patterns while minimizing user wait time during Git commands.
183+ A variety of configuration options are available to allow customizing this
184+ process. The default maintenance options focus on operations that complete
185+ quickly, even on large repositories.
186+
187+ Users may find some cases where scheduled maintenance tasks do not run as
188+ frequently as intended. Each `git maintenance run` command takes a lock on
189+ the repository's object database, and this prevents other concurrent
190+ `git maintenance run` commands from running on the same repository. Without
191+ this safeguard, competing processes could leave the repository in an
192+ unpredictable state.
193+
194+ The background maintenance schedule runs `git maintenance run` processes
195+ on an hourly basis. Each run executes the "hourly" tasks. At midnight,
196+ that process also executes the "daily" tasks. At midnight on the first day
197+ of the week, that process also executes the "weekly" tasks. A single
198+ process iterates over each registered repository, performing the scheduled
199+ tasks for that frequency. Depending on the number of registered
200+ repositories and their sizes, this process may take longer than an hour.
201+ In this case, multiple `git maintenance run` commands may run on the same
202+ repository at the same time, colliding on the object database lock. This
203+ results in one of the two tasks not running.
204+
205+ If you find that some maintenance windows are taking longer than one hour
206+ to complete, then consider reducing the complexity of your maintenance
207+ tasks. For example, the `gc` task is much slower than the
208+ `incremental-repack` task. However, this comes at a cost of a slightly
209+ larger object database. Consider moving more expensive tasks to be run
210+ less frequently.
211+
212+ Expert users may consider scheduling their own maintenance tasks using a
213+ different schedule than is available through `git maintenance start` and
214+ Git configuration options. These users should be aware of the object
215+ database lock and how concurrent `git maintenance run` commands behave.
216+ Further, the `git gc` command should not be combined with
217+ `git maintenance run` commands. `git gc` modifies the object database
218+ but does not take the lock in the same way as `git maintenance run`. If
219+ possible, use `git maintenance run --task=gc` instead of `git gc`.
220+
221+
125222GIT
126223---
127224Part of the linkgit:git[1] suite
0 commit comments