Merge branch 'ds/maintenance-part-2'
"git maintenance", an extended big brother of "git gc", continues to evolve. * ds/maintenance-part-2: maintenance: add incremental-repack auto condition maintenance: auto-size incremental-repack batch maintenance: add incremental-repack task midx: use start_delayed_progress() midx: enable core.multiPackIndex by default maintenance: create auto condition for loose-objects maintenance: add loose-objects task maintenance: add prefetch task
This commit is contained in:
@ -606,8 +606,8 @@ core.useReplaceRefs::
|
||||
|
||||
core.multiPackIndex::
|
||||
Use the multi-pack-index file to track multiple packfiles using a
|
||||
single index. See link:technical/multi-pack-index.html[the
|
||||
multi-pack-index design document].
|
||||
single index. See linkgit:git-multi-pack-index[1] for more
|
||||
information. Defaults to true.
|
||||
|
||||
core.sparseCheckout::
|
||||
Enable "sparse checkout" feature. See linkgit:git-sparse-checkout[1]
|
||||
|
@ -14,3 +14,21 @@ maintenance.commit-graph.auto::
|
||||
reachable commits that are not in the commit-graph file is at least
|
||||
the value of `maintenance.commit-graph.auto`. The default value is
|
||||
100.
|
||||
|
||||
maintenance.loose-objects.auto::
|
||||
This integer config option controls how often the `loose-objects` task
|
||||
should be run as part of `git maintenance run --auto`. If zero, then
|
||||
the `loose-objects` task will not run with the `--auto` option. A
|
||||
negative value will force the task to run every time. Otherwise, a
|
||||
positive value implies the command should run when the number of
|
||||
loose objects is at least the value of `maintenance.loose-objects.auto`.
|
||||
The default value is 100.
|
||||
|
||||
maintenance.incremental-repack.auto::
|
||||
This integer config option controls how often the `incremental-repack`
|
||||
task should be run as part of `git maintenance run --auto`. If zero,
|
||||
then the `incremental-repack` task will not run with the `--auto`
|
||||
option. A negative value will force the task to run every time.
|
||||
Otherwise, a positive value implies the command should run when the
|
||||
number of pack-files not in the multi-pack-index is at least the value
|
||||
of `maintenance.incremental-repack.auto`. The default value is 10.
|
||||
|
@ -47,6 +47,21 @@ commit-graph::
|
||||
`commit-graph-chain` file. They will be deleted by a later run based
|
||||
on the expiration delay.
|
||||
|
||||
prefetch::
|
||||
The `prefetch` task updates the object directory with the latest
|
||||
objects from all registered remotes. For each remote, a `git fetch`
|
||||
command is run. The refmap is custom to avoid updating local or remote
|
||||
branches (those in `refs/heads` or `refs/remotes`). Instead, the
|
||||
remote refs are stored in `refs/prefetch/<remote>/`. Also, tags are
|
||||
not updated.
|
||||
+
|
||||
This is done to avoid disrupting the remote-tracking branches. The end users
|
||||
expect these refs to stay unmoved unless they initiate a fetch. With prefetch
|
||||
task, however, the objects necessary to complete a later real fetch would
|
||||
already be obtained, so the real fetch would go faster. In the ideal case,
|
||||
it will just become an update to bunch of remote-tracking branches without
|
||||
any object transfer.
|
||||
|
||||
gc::
|
||||
Clean up unnecessary files and optimize the local repository. "GC"
|
||||
stands for "garbage collection," but this task performs many
|
||||
@ -55,6 +70,39 @@ gc::
|
||||
be disruptive in some situations, as it deletes stale data. See
|
||||
linkgit:git-gc[1] for more details on garbage collection in Git.
|
||||
|
||||
loose-objects::
|
||||
The `loose-objects` job cleans up loose objects and places them into
|
||||
pack-files. In order to prevent race conditions with concurrent Git
|
||||
commands, it follows a two-step process. First, it deletes any loose
|
||||
objects that already exist in a pack-file; concurrent Git processes
|
||||
will examine the pack-file for the object data instead of the loose
|
||||
object. Second, it creates a new pack-file (starting with "loose-")
|
||||
containing a batch of loose objects. The batch size is limited to 50
|
||||
thousand objects to prevent the job from taking too long on a
|
||||
repository with many loose objects. The `gc` task writes unreachable
|
||||
objects as loose objects to be cleaned up by a later step only if
|
||||
they are not re-added to a pack-file; for this reason it is not
|
||||
advisable to enable both the `loose-objects` and `gc` tasks at the
|
||||
same time.
|
||||
|
||||
incremental-repack::
|
||||
The `incremental-repack` job repacks the object directory
|
||||
using the `multi-pack-index` feature. In order to prevent race
|
||||
conditions with concurrent Git commands, it follows a two-step
|
||||
process. First, it calls `git multi-pack-index expire` to delete
|
||||
pack-files unreferenced by the `multi-pack-index` file. Second, it
|
||||
calls `git multi-pack-index repack` to select several small
|
||||
pack-files and repack them into a 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.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
--auto::
|
||||
|
Reference in New Issue
Block a user