bigger one, and then update the
	`multi-pack-index` entries that refer to the small pack-files to
	refer to the new pack-file. This prepares those small pack-files
	for deletion upon the next run of `git multi-pack-index expire`.
	The selection of the small pack-files is such that the expected
	size of the big pack-file is at least the batch size; see the
	`--batch-size` option for the `repack` subcommand in
	linkgit:git-multi-pack-index[1]. The default batch-size is zero,
	which is a special case that attempts to repack all pack-files
	into a single pack-file.

pack-refs::
	The `pack-refs` task collects the loose reference files and
	collects them into a single file. This speeds up operations that
	need to iterate across many references. See linkgit:git-pack-refs[1]
	for more information.

reflog-expire::
	The `reflog-expire` task deletes any entries in the reflog older than the
	expiry threshold. See linkgit:git-reflog[1] for more information.

rerere-gc::
	The `rerere-gc` task invokes garbage collection for stale entries in
	the rerere cache. See linkgit:git-rerere[1] for more information.

worktree-prune::
	The `worktree-prune` task deletes stale or broken worktrees. See
	linkit:git-worktree[1] for more information.

OPTIONS
-------
--auto::
	When combined with the `run` subcommand, run maintenance tasks
	only if certain thresholds are met. For example, the `gc` task
	runs when the number of loose objects exceeds the number stored
	in the `gc.auto` config setting, or when the number of pack-files
	exceeds the `gc.autoPackLimit` config setting. Not compatible with
	the `--schedule` option.

--schedule::
	When combined with the `run` subcommand, run maintenance tasks
	only if certain time conditions are met, as specified by the
	`maintenance.<task>.schedule` config value for each `<task>`.
	This config value specifies a number of seconds since the last
	time that task ran, according to the `maintenance.<task>.lastRun`
	config value. The tasks that are tested are those provided by
	the `--task=<task>` option(s) or those with
	`maintenance.<task>.enabled` set to true.

--quiet::
	Do not report progress or other information over `stderr`.

--task=<task>::
	If this option is specified one or more times, then only run the
	specified tasks in the specified order. If no `--task=<task>`
	arguments are specified, then only the tasks with
	`maintenance.<task>.enabled` configured as `true` are considered.
	See the 'TASKS' section for the list of accepted `<task>` values.

--scheduler=auto|crontab|systemd-timer|launchctl|schtasks::
	When combined with the `start` subcommand, specify the scheduler
	for running the hourly, daily and weekly executions of
	`git maintenance run`.
	Possible values for `<scheduler>` are `auto`, `crontab`
	(POSIX), `systemd-timer` (Linux), `launchctl` (macOS), and
	`schtasks` (Windows). When `auto` is specified, the
	appropriate platform-specific scheduler is used; on Linux,
	`systemd-timer` is used if available, otherwise
	`crontab`. Default is `auto`.


TROUBLESHOOTING
---------------
The `git maintenance` command is designed to simplify the repository
maintenance patterns while minimizing user wait time during Git commands.
A variety of configuration options are available to allow customizing this
process. The default maintenance options focus on operations that complete
quickly, even on large repositories.

Users may find some cases where scheduled maintenance tasks do not run as
frequently as intended. Each `git maintenance run` command takes a lock on
the repository's object database, and this prevents other concurrent
`git maintenance run` commands from running on the same repository. Without
this safeguard, competing processes could leave the repository in an
unpredictable state.

The background maintenance schedule runs `git maintenance run` processes
on an hourly basis. Each run executes the "hourly" tasks. At midnight,
that process also executes the "daily" tasks. At midnight on the first day
of the