@@ -20,17 +20,16 @@ created from prior invocations of 'git add', packing refs, pruning
20
20
reflog, rerere metadata or stale working trees. May also update ancillary
21
21
indexes such as the commit-graph.
22
22
23
- Users are encouraged to run this task on a regular basis within
24
- each repository to maintain good disk space utilization and good
25
- operating performance.
23
+ When common porcelain operations that create objects are run, they
24
+ will check whether the repository has grown substantially since the
25
+ last maintenance, and if so run `git gc` automatically. See `gc.auto`
26
+ below for how to disable this behavior.
26
27
27
- Some git commands may automatically run 'git gc'; see the `--auto` flag
28
- below for details. If you know what you're doing and all you want is to
29
- disable this behavior permanently without further considerations, just do:
30
-
31
- ----------------------
32
- $ git config --global gc.auto 0
33
- ----------------------
28
+ Running `git gc` manually should only be needed when adding objects to
29
+ a repository without regularly running such porcelain commands, to do
30
+ a one-off repository optimization, or e.g. to clean up a suboptimal
31
+ mass-import. See the "PACKFILE OPTIMIZATION" section in
32
+ linkgit:git-fast-import[1] for more details on the import case.
34
33
35
34
OPTIONS
36
35
-------
@@ -40,35 +39,17 @@ OPTIONS
40
39
space utilization and performance. This option will cause
41
40
'git gc' to more aggressively optimize the repository at the expense
42
41
of taking much more time. The effects of this optimization are
43
- persistent, so this option only needs to be used occasionally; every
44
- few hundred changesets or so.
42
+ mostly persistent. See the "AGGRESSIVE" section below for details.
45
43
46
44
--auto::
47
45
With this option, 'git gc' checks whether any housekeeping is
48
46
required; if not, it exits without performing any work.
49
- Some git commands run `git gc --auto` after performing
50
- operations that could create many loose objects. Housekeeping
51
- is required if there are too many loose objects or too many
52
- packs in the repository.
53
- +
54
- If the number of loose objects exceeds the value of the `gc.auto`
55
- configuration variable, then all loose objects are combined into a
56
- single pack using `git repack -d -l`. Setting the value of `gc.auto`
57
- to 0 disables automatic packing of loose objects.
58
47
+
59
- If the number of packs exceeds the value of `gc.autoPackLimit`,
60
- then existing packs (except those marked with a `.keep` file
61
- or over `gc.bigPackThreshold` limit)
62
- are consolidated into a single pack by using the `-A` option of
63
- 'git repack'.
64
- If the amount of memory is estimated not enough for `git repack` to
65
- run smoothly and `gc.bigPackThreshold` is not set, the largest
66
- pack will also be excluded (this is the equivalent of running `git gc`
67
- with `--keep-base-pack`).
68
- Setting `gc.autoPackLimit` to 0 disables automatic consolidation of
69
- packs.
48
+ See the `gc.auto` option in the "CONFIGURATION" section below for how
49
+ this heuristic works.
70
50
+
71
- If houskeeping is required due to many loose objects or packs, all
51
+ Once housekeeping is triggered by exceeding the limits of
52
+ configuration options such as `gc.auto` and `gc.autoPackLimit`, all
72
53
other housekeeping tasks (e.g. rerere, working trees, reflog...) will
73
54
be performed as well.
74
55
@@ -96,69 +77,39 @@ be performed as well.
96
77
`.keep` files are consolidated into a single pack. When this
97
78
option is used, `gc.bigPackThreshold` is ignored.
98
79
80
+ AGGRESSIVE
81
+ ----------
82
+
83
+ When the `--aggressive` option is supplied, linkgit:git-repack[1] will
84
+ be invoked with the `-f` flag, which in turn will pass
85
+ `--no-reuse-delta` to linkgit:git-pack-objects[1]. This will throw
86
+ away any existing deltas and re-compute them, at the expense of
87
+ spending much more time on the repacking.
88
+
89
+ The effects of this are mostly persistent, e.g. when packs and loose
90
+ objects are coalesced into one another pack the existing deltas in
91
+ that pack might get re-used, but there are also various cases where we
92
+ might pick a sub-optimal delta from a newer pack instead.
93
+
94
+ Furthermore, supplying `--aggressive` will tweak the `--depth` and
95
+ `--window` options passed to linkgit:git-repack[1]. See the
96
+ `gc.aggressiveDepth` and `gc.aggressiveWindow` settings below. By
97
+ using a larger window size we're more likely to find more optimal
98
+ deltas.
99
+
100
+ It's probably not worth it to use this option on a given repository
101
+ without running tailored performance benchmarks on it. It takes a lot
102
+ more time, and the resulting space/delta optimization may or may not
103
+ be worth it. Not using this at all is the right trade-off for most
104
+ users and their repositories.
105
+
99
106
CONFIGURATION
100
107
-------------
101
108
102
- The optional configuration variable `gc.reflogExpire` can be
103
- set to indicate how long historical entries within each branch's
104
- reflog should remain available in this repository. The setting is
105
- expressed as a length of time, for example '90 days' or '3 months'.
106
- It defaults to '90 days'.
107
-
108
- The optional configuration variable `gc.reflogExpireUnreachable`
109
- can be set to indicate how long historical reflog entries which
110
- are not part of the current branch should remain available in
111
- this repository. These types of entries are generally created as
112
- a result of using `git commit --amend` or `git rebase` and are the
113
- commits prior to the amend or rebase occurring. Since these changes
114
- are not part of the current project most users will want to expire
115
- them sooner. This option defaults to '30 days'.
116
-
117
- The above two configuration variables can be given to a pattern. For
118
- example, this sets non-default expiry values only to remote-tracking
119
- branches:
120
-
121
- ------------
122
- [gc "refs/remotes/*"]
123
- reflogExpire = never
124
- reflogExpireUnreachable = 3 days
125
- ------------
126
-
127
- The optional configuration variable `gc.rerereResolved` indicates
128
- how long records of conflicted merge you resolved earlier are
129
- kept. This defaults to 60 days.
130
-
131
- The optional configuration variable `gc.rerereUnresolved` indicates
132
- how long records of conflicted merge you have not resolved are
133
- kept. This defaults to 15 days.
134
-
135
- The optional configuration variable `gc.packRefs` determines if
136
- 'git gc' runs 'git pack-refs'. This can be set to "notbare" to enable
137
- it within all non-bare repos or it can be set to a boolean value.
138
- This defaults to true.
139
-
140
- The optional configuration variable `gc.writeCommitGraph` determines if
141
- 'git gc' should run 'git commit-graph write'. This can be set to a
142
- boolean value. This defaults to false.
143
-
144
- The optional configuration variable `gc.aggressiveWindow` controls how
145
- much time is spent optimizing the delta compression of the objects in
146
- the repository when the --aggressive option is specified. The larger
147
- the value, the more time is spent optimizing the delta compression. See
148
- the documentation for the --window option in linkgit:git-repack[1] for
149
- more details. This defaults to 250.
150
-
151
- Similarly, the optional configuration variable `gc.aggressiveDepth`
152
- controls --depth option in linkgit:git-repack[1]. This defaults to 50.
153
-
154
- The optional configuration variable `gc.pruneExpire` controls how old
155
- the unreferenced loose objects have to be before they are pruned. The
156
- default is "2 weeks ago".
157
-
158
- Optional configuration variable `gc.worktreePruneExpire` controls how
159
- old a stale working tree should be before `git worktree prune` deletes
160
- it. Default is "3 months ago".
109
+ The below documentation is the same as what's found in
110
+ linkgit:git-config[1]:
161
111
112
+ include::config/gc.txt[]
162
113
163
114
NOTES
164
115
-----
@@ -168,8 +119,8 @@ anywhere in your repository. In
168
119
particular, it will keep not only objects referenced by your current set
169
120
of branches and tags, but also objects referenced by the index,
170
121
remote-tracking branches, refs saved by 'git filter-branch' in
171
- refs/original/, or reflogs (which may reference commits in branches
172
- that were later amended or rewound).
122
+ refs/original/, reflogs (which may reference commits in branches
123
+ that were later amended or rewound), and anything else in the refs/* namespace .
173
124
If you are expecting some objects to be deleted and they aren't, check
174
125
all of those locations and decide whether it makes sense in your case to
175
126
remove those references.
@@ -190,8 +141,7 @@ mitigate this problem:
190
141
191
142
However, these features fall short of a complete solution, so users who
192
143
run commands concurrently have to live with some risk of corruption (which
193
- seems to be low in practice) unless they turn off automatic garbage
194
- collection with 'git config gc.auto 0'.
144
+ seems to be low in practice).
195
145
196
146
HOOKS
197
147
-----
0 commit comments