@@ -47,6 +47,21 @@ commit-graph::
47
47
`commit-graph-chain` file. They will be deleted by a later run based
48
48
on the expiration delay.
49
49
50
+ prefetch::
51
+ The `prefetch` task updates the object directory with the latest
52
+ objects from all registered remotes. For each remote, a `git fetch`
53
+ command is run. The refmap is custom to avoid updating local or remote
54
+ branches (those in `refs/heads` or `refs/remotes`). Instead, the
55
+ remote refs are stored in `refs/prefetch/<remote>/`. Also, tags are
56
+ not updated.
57
+ +
58
+ This is done to avoid disrupting the remote-tracking branches. The end users
59
+ expect these refs to stay unmoved unless they initiate a fetch. With prefetch
60
+ task, however, the objects necessary to complete a later real fetch would
61
+ already be obtained, so the real fetch would go faster. In the ideal case,
62
+ it will just become an update to bunch of remote-tracking branches without
63
+ any object transfer.
64
+
50
65
gc::
51
66
Clean up unnecessary files and optimize the local repository. "GC"
52
67
stands for "garbage collection," but this task performs many
55
70
be disruptive in some situations, as it deletes stale data. See
56
71
linkgit:git-gc[1] for more details on garbage collection in Git.
57
72
73
+ loose-objects::
74
+ The `loose-objects` job cleans up loose objects and places them into
75
+ pack-files. In order to prevent race conditions with concurrent Git
76
+ commands, it follows a two-step process. First, it deletes any loose
77
+ objects that already exist in a pack-file; concurrent Git processes
78
+ will examine the pack-file for the object data instead of the loose
79
+ object. Second, it creates a new pack-file (starting with "loose-")
80
+ containing a batch of loose objects. The batch size is limited to 50
81
+ thousand objects to prevent the job from taking too long on a
82
+ repository with many loose objects. The `gc` task writes unreachable
83
+ objects as loose objects to be cleaned up by a later step only if
84
+ they are not re-added to a pack-file; for this reason it is not
85
+ advisable to enable both the `loose-objects` and `gc` tasks at the
86
+ same time.
87
+
88
+ incremental-repack::
89
+ The `incremental-repack` job repacks the object directory
90
+ using the `multi-pack-index` feature. In order to prevent race
91
+ conditions with concurrent Git commands, it follows a two-step
92
+ process. First, it calls `git multi-pack-index expire` to delete
93
+ pack-files unreferenced by the `multi-pack-index` file. Second, it
94
+ calls `git multi-pack-index repack` to select several small
95
+ pack-files and repack them into a bigger one, and then update the
96
+ `multi-pack-index` entries that refer to the small pack-files to
97
+ refer to the new pack-file. This prepares those small pack-files
98
+ for deletion upon the next run of `git multi-pack-index expire`.
99
+ The selection of the small pack-files is such that the expected
100
+ size of the big pack-file is at least the batch size; see the
101
+ `--batch-size` option for the `repack` subcommand in
102
+ linkgit:git-multi-pack-index[1]. The default batch-size is zero,
103
+ which is a special case that attempts to repack all pack-files
104
+ into a single pack-file.
105
+
58
106
OPTIONS
59
107
-------
60
108
--auto::
0 commit comments