maintenance: create basic maintenance runner
The 'gc' builtin is our current entrypoint for automatically maintaining
a repository. This one tool does many operations, such as repacking the
repository, packing refs, and rewriting the commit-graph file. The name
implies it performs "garbage collection" which means several different
things, and some users may not want to use this operation that rewrites
the entire object database.
Create a new 'maintenance' builtin that will become a more general-
purpose command. To start, it will only support the 'run' subcommand,
but will later expand to add subcommands for scheduling maintenance in
the background.
For now, the 'maintenance' builtin is a thin shim over the 'gc' builtin.
In fact, the only option is the '--auto' toggle, which is handed
directly to the 'gc' builtin. The current change is isolated to this
simple operation to prevent more interesting logic from being lost in
all of the boilerplate of adding a new builtin.
Use existing builtin/gc.c file because we want to share code between the
two builtins. It is possible that we will have 'maintenance' replace the
'gc' builtin entirely at some point, leaving 'git gc' as an alias for
some specific arguments to 'git maintenance run'.
Create a new test_subcommand helper that allows us to test if a certain
subcommand was run. It requires storing the GIT_TRACE2_EVENT logs in a
file. A negation mode is available that will be used in later tests.
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-17 20:11:42 +02:00
|
|
|
git-maintenance(1)
|
|
|
|
|
==================
|
|
|
|
|
|
|
|
|
|
NAME
|
|
|
|
|
----
|
|
|
|
|
git-maintenance - Run tasks to optimize Git repository data
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
|
--------
|
|
|
|
|
[verse]
|
|
|
|
|
'git maintenance' run [<options>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
|
-----------
|
|
|
|
|
Run tasks to optimize Git repository data, speeding up other Git commands
|
|
|
|
|
and reducing storage requirements for the repository.
|
|
|
|
|
|
|
|
|
|
Git commands that add repository data, such as `git add` or `git fetch`,
|
|
|
|
|
are optimized for a responsive user experience. These commands do not take
|
|
|
|
|
time to optimize the Git data, since such optimizations scale with the full
|
|
|
|
|
size of the repository while these user commands each perform a relatively
|
|
|
|
|
small action.
|
|
|
|
|
|
|
|
|
|
The `git maintenance` command provides flexibility for how to optimize the
|
|
|
|
|
Git repository.
|
|
|
|
|
|
|
|
|
|
SUBCOMMANDS
|
|
|
|
|
-----------
|
|
|
|
|
|
|
|
|
|
run::
|
2020-09-17 20:11:49 +02:00
|
|
|
Run one or more maintenance tasks. If one or more `--task` options
|
|
|
|
|
are specified, then those tasks are run in that order. Otherwise,
|
|
|
|
|
the tasks are determined by which `maintenance.<task>.enabled`
|
|
|
|
|
config options are true. By default, only `maintenance.gc.enabled`
|
|
|
|
|
is true.
|
maintenance: create basic maintenance runner
The 'gc' builtin is our current entrypoint for automatically maintaining
a repository. This one tool does many operations, such as repacking the
repository, packing refs, and rewriting the commit-graph file. The name
implies it performs "garbage collection" which means several different
things, and some users may not want to use this operation that rewrites
the entire object database.
Create a new 'maintenance' builtin that will become a more general-
purpose command. To start, it will only support the 'run' subcommand,
but will later expand to add subcommands for scheduling maintenance in
the background.
For now, the 'maintenance' builtin is a thin shim over the 'gc' builtin.
In fact, the only option is the '--auto' toggle, which is handed
directly to the 'gc' builtin. The current change is isolated to this
simple operation to prevent more interesting logic from being lost in
all of the boilerplate of adding a new builtin.
Use existing builtin/gc.c file because we want to share code between the
two builtins. It is possible that we will have 'maintenance' replace the
'gc' builtin entirely at some point, leaving 'git gc' as an alias for
some specific arguments to 'git maintenance run'.
Create a new test_subcommand helper that allows us to test if a certain
subcommand was run. It requires storing the GIT_TRACE2_EVENT logs in a
file. A negation mode is available that will be used in later tests.
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-17 20:11:42 +02:00
|
|
|
|
|
|
|
|
TASKS
|
|
|
|
|
-----
|
|
|
|
|
|
2020-09-17 20:11:46 +02:00
|
|
|
commit-graph::
|
|
|
|
|
The `commit-graph` job updates the `commit-graph` files incrementally,
|
|
|
|
|
then verifies that the written data is correct. The incremental
|
|
|
|
|
write is safe to run alongside concurrent Git processes since it
|
|
|
|
|
will not expire `.graph` files that were in the previous
|
|
|
|
|
`commit-graph-chain` file. They will be deleted by a later run based
|
|
|
|
|
on the expiration delay.
|
|
|
|
|
|
maintenance: create basic maintenance runner
The 'gc' builtin is our current entrypoint for automatically maintaining
a repository. This one tool does many operations, such as repacking the
repository, packing refs, and rewriting the commit-graph file. The name
implies it performs "garbage collection" which means several different
things, and some users may not want to use this operation that rewrites
the entire object database.
Create a new 'maintenance' builtin that will become a more general-
purpose command. To start, it will only support the 'run' subcommand,
but will later expand to add subcommands for scheduling maintenance in
the background.
For now, the 'maintenance' builtin is a thin shim over the 'gc' builtin.
In fact, the only option is the '--auto' toggle, which is handed
directly to the 'gc' builtin. The current change is isolated to this
simple operation to prevent more interesting logic from being lost in
all of the boilerplate of adding a new builtin.
Use existing builtin/gc.c file because we want to share code between the
two builtins. It is possible that we will have 'maintenance' replace the
'gc' builtin entirely at some point, leaving 'git gc' as an alias for
some specific arguments to 'git maintenance run'.
Create a new test_subcommand helper that allows us to test if a certain
subcommand was run. It requires storing the GIT_TRACE2_EVENT logs in a
file. A negation mode is available that will be used in later tests.
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-17 20:11:42 +02:00
|
|
|
gc::
|
|
|
|
|
Clean up unnecessary files and optimize the local repository. "GC"
|
|
|
|
|
stands for "garbage collection," but this task performs many
|
|
|
|
|
smaller tasks. This task can be expensive for large repositories,
|
|
|
|
|
as it repacks all Git objects into a single pack-file. It can also
|
|
|
|
|
be disruptive in some situations, as it deletes stale data. See
|
|
|
|
|
linkgit:git-gc[1] for more details on garbage collection in Git.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2020-09-17 20:11:43 +02:00
|
|
|
--quiet::
|
|
|
|
|
Do not report progress or other information over `stderr`.
|
|
|
|
|
|
2020-09-17 20:11:47 +02:00
|
|
|
--task=<task>::
|
|
|
|
|
If this option is specified one or more times, then only run the
|
2020-09-17 20:11:49 +02:00
|
|
|
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.
|
2020-09-17 20:11:47 +02:00
|
|
|
|
maintenance: create basic maintenance runner
The 'gc' builtin is our current entrypoint for automatically maintaining
a repository. This one tool does many operations, such as repacking the
repository, packing refs, and rewriting the commit-graph file. The name
implies it performs "garbage collection" which means several different
things, and some users may not want to use this operation that rewrites
the entire object database.
Create a new 'maintenance' builtin that will become a more general-
purpose command. To start, it will only support the 'run' subcommand,
but will later expand to add subcommands for scheduling maintenance in
the background.
For now, the 'maintenance' builtin is a thin shim over the 'gc' builtin.
In fact, the only option is the '--auto' toggle, which is handed
directly to the 'gc' builtin. The current change is isolated to this
simple operation to prevent more interesting logic from being lost in
all of the boilerplate of adding a new builtin.
Use existing builtin/gc.c file because we want to share code between the
two builtins. It is possible that we will have 'maintenance' replace the
'gc' builtin entirely at some point, leaving 'git gc' as an alias for
some specific arguments to 'git maintenance run'.
Create a new test_subcommand helper that allows us to test if a certain
subcommand was run. It requires storing the GIT_TRACE2_EVENT logs in a
file. A negation mode is available that will be used in later tests.
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-17 20:11:42 +02:00
|
|
|
GIT
|
|
|
|
|
---
|
|
|
|
|
Part of the linkgit:git[1] suite
|