@@ -29,13 +29,44 @@ Git repository.
29
29
SUBCOMMANDS
30
30
-----------
31
31
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
+ If your repository has no 'maintenance.<task>.schedule' configuration
42
+ values set, then Git will set configuration values to some recommended
43
+ settings. These settings disable foreground maintenance while performing
44
+ maintenance tasks in the background that will not interrupt foreground Git
45
+ operations.
46
+
32
47
run::
33
48
Run one or more maintenance tasks. If one or more `--task` options
34
49
are specified, then those tasks are run in that order. Otherwise,
35
50
the tasks are determined by which `maintenance.<task>.enabled`
36
51
config options are true. By default, only `maintenance.gc.enabled`
37
52
is true.
38
53
54
+ start::
55
+ Start running maintenance on the current repository. This performs
56
+ the same config updates as the `register` subcommand, then updates
57
+ the background scheduler to run `git maintenance run --scheduled`
58
+ on an hourly basis.
59
+
60
+ stop::
61
+ Halt the background maintenance schedule. The current repository
62
+ is not removed from the list of maintained repositories, in case
63
+ the background maintenance is restarted later.
64
+
65
+ unregister::
66
+ Remove the current repository from background maintenance. This
67
+ only removes the repository from the configured list. It does not
68
+ stop the background maintenance processes from running.
69
+
39
70
TASKS
40
71
-----
41
72
@@ -110,7 +141,18 @@ OPTIONS
110
141
only if certain thresholds are met. For example, the `gc` task
111
142
runs when the number of loose objects exceeds the number stored
112
143
in the `gc.auto` config setting, or when the number of pack-files
113
- exceeds the `gc.autoPackLimit` config setting.
144
+ exceeds the `gc.autoPackLimit` config setting. Not compatible with
145
+ the `--schedule` option.
146
+
147
+ --schedule::
148
+ When combined with the `run` subcommand, run maintenance tasks
149
+ only if certain time conditions are met, as specified by the
150
+ `maintenance.<task>.schedule` config value for each `<task>`.
151
+ This config value specifies a number of seconds since the last
152
+ time that task ran, according to the `maintenance.<task>.lastRun`
153
+ config value. The tasks that are tested are those provided by
154
+ the `--task=<task>` option(s) or those with
155
+ `maintenance.<task>.enabled` set to true.
114
156
115
157
--quiet::
116
158
Do not report progress or other information over `stderr`.
@@ -122,6 +164,50 @@ OPTIONS
122
164
`maintenance.<task>.enabled` configured as `true` are considered.
123
165
See the 'TASKS' section for the list of accepted `<task>` values.
124
166
167
+
168
+ TROUBLESHOOTING
169
+ ---------------
170
+ The `git maintenance` command is designed to simplify the repository
171
+ maintenance patterns while minimizing user wait time during Git commands.
172
+ A variety of configuration options are available to allow customizing this
173
+ process. The default maintenance options focus on operations that complete
174
+ quickly, even on large repositories.
175
+
176
+ Users may find some cases where scheduled maintenance tasks do not run as
177
+ frequently as intended. Each `git maintenance run` command takes a lock on
178
+ the repository's object database, and this prevents other concurrent
179
+ `git maintenance run` commands from running on the same repository. Without
180
+ this safeguard, competing processes could leave the repository in an
181
+ unpredictable state.
182
+
183
+ The background maintenance schedule runs `git maintenance run` processes
184
+ on an hourly basis. Each run executes the "hourly" tasks. At midnight,
185
+ that process also executes the "daily" tasks. At midnight on the first day
186
+ of the week, that process also executes the "weekly" tasks. A single
187
+ process iterates over each registered repository, performing the scheduled
188
+ tasks for that frequency. Depending on the number of registered
189
+ repositories and their sizes, this process may take longer than an hour.
190
+ In this case, multiple `git maintenance run` commands may run on the same
191
+ repository at the same time, colliding on the object database lock. This
192
+ results in one of the two tasks not running.
193
+
194
+ If you find that some maintenance windows are taking longer than one hour
195
+ to complete, then consider reducing the complexity of your maintenance
196
+ tasks. For example, the `gc` task is much slower than the
197
+ `incremental-repack` task. However, this comes at a cost of a slightly
198
+ larger object database. Consider moving more expensive tasks to be run
199
+ less frequently.
200
+
201
+ Expert users may consider scheduling their own maintenance tasks using a
202
+ different schedule than is available through `git maintenance start` and
203
+ Git configuration options. These users should be aware of the object
204
+ database lock and how concurrent `git maintenance run` commands behave.
205
+ Further, the `git gc` command should not be combined with
206
+ `git maintenance run` commands. `git gc` modifies the object database
207
+ but does not take the lock in the same way as `git maintenance run`. If
208
+ possible, use `git maintenance run --task=gc` instead of `git gc`.
209
+
210
+
125
211
GIT
126
212
---
127
213
Part of the linkgit:git[1] suite
0 commit comments