Skip to content

Commit ac70c53

Browse files
committed
Merge branch 'ab/gc-docs'
Update docs around "gc". * ab/gc-docs: gc docs: remove incorrect reference to gc.auto=0 gc docs: clarify that "gc" doesn't throw away referenced objects gc docs: note "gc --aggressive" in "fast-import" gc docs: downplay the usefulness of --aggressive gc docs: note how --aggressive impacts --window & --depth gc docs: fix formatting for "gc.writeCommitGraph" gc docs: re-flow the "gc.*" section in "config" gc docs: include the "gc.*" section from "config" in "gc" gc docs: clean grammar for "gc.bigPackThreshold" gc docs: stop noting "repack" flags gc docs: modernize the advice for manually running "gc"
2 parents 01f8d78 + 0044f77 commit ac70c53

File tree

3 files changed

+86
-101
lines changed

3 files changed

+86
-101
lines changed

Documentation/config/gc.txt

Lines changed: 33 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,25 +1,42 @@
11
gc.aggressiveDepth::
22
The depth parameter used in the delta compression
33
algorithm used by 'git gc --aggressive'. This defaults
4-
to 50.
4+
to 50, which is the default for the `--depth` option when
5+
`--aggressive` isn't in use.
6+
+
7+
See the documentation for the `--depth` option in
8+
linkgit:git-repack[1] for more details.
59

610
gc.aggressiveWindow::
711
The window size parameter used in the delta compression
812
algorithm used by 'git gc --aggressive'. This defaults
9-
to 250.
13+
to 250, which is a much more aggressive window size than
14+
the default `--window` of 10.
15+
+
16+
See the documentation for the `--window` option in
17+
linkgit:git-repack[1] for more details.
1018

1119
gc.auto::
1220
When there are approximately more than this many loose
1321
objects in the repository, `git gc --auto` will pack them.
1422
Some Porcelain commands use this command to perform a
1523
light-weight garbage collection from time to time. The
16-
default value is 6700. Setting this to 0 disables it.
24+
default value is 6700.
25+
+
26+
Setting this to 0 disables not only automatic packing based on the
27+
number of loose objects, but any other heuristic `git gc --auto` will
28+
otherwise use to determine if there's work to do, such as
29+
`gc.autoPackLimit`.
1730

1831
gc.autoPackLimit::
1932
When there are more than this many packs that are not
2033
marked with `*.keep` file in the repository, `git gc
2134
--auto` consolidates them into one larger pack. The
2235
default value is 50. Setting this to 0 disables it.
36+
Setting `gc.auto` to 0 will also disable this.
37+
+
38+
See the `gc.bigPackThreshold` configuration variable below. When in
39+
use, it'll affect how the auto pack limit works.
2340

2441
gc.autoDetach::
2542
Make `git gc --auto` return immediately and run in background
@@ -36,11 +53,16 @@ Note that if the number of kept packs is more than gc.autoPackLimit,
3653
this configuration variable is ignored, all packs except the base pack
3754
will be repacked. After this the number of packs should go below
3855
gc.autoPackLimit and gc.bigPackThreshold should be respected again.
56+
+
57+
If the amount of memory estimated for `git repack` to run smoothly is
58+
not available and `gc.bigPackThreshold` is not set, the largest pack
59+
will also be excluded (this is the equivalent of running `git gc` with
60+
`--keep-base-pack`).
3961

4062
gc.writeCommitGraph::
4163
If true, then gc will rewrite the commit-graph file when
42-
linkgit:git-gc[1] is run. When using linkgit:git-gc[1]
43-
'--auto' the commit-graph will be updated if housekeeping is
64+
linkgit:git-gc[1] is run. When using `git gc --auto`
65+
the commit-graph will be updated if housekeeping is
4466
required. Default is false. See linkgit:git-commit-graph[1]
4567
for details.
4668

@@ -94,6 +116,12 @@ gc.<pattern>.reflogExpireUnreachable::
94116
With "<pattern>" (e.g. "refs/stash")
95117
in the middle, the setting applies only to the refs that
96118
match the <pattern>.
119+
+
120+
These types of entries are generally created as a result of using `git
121+
commit --amend` or `git rebase` and are the commits prior to the amend
122+
or rebase occurring. Since these changes are not part of the current
123+
project most users will want to expire them sooner, which is why the
124+
default is more aggressive than `gc.reflogExpire`.
97125

98126
gc.rerereResolved::
99127
Records of conflicted merge you resolved earlier are

Documentation/git-fast-import.txt

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1398,6 +1398,13 @@ deltas are suboptimal (see above) then also adding the `-f` option
13981398
to force recomputation of all deltas can significantly reduce the
13991399
final packfile size (30-50% smaller can be quite typical).
14001400

1401+
Instead of running `git repack` you can also run `git gc
1402+
--aggressive`, which will also optimize other things after an import
1403+
(e.g. pack loose refs). As noted in the "AGGRESSIVE" section in
1404+
linkgit:git-gc[1] the `--aggressive` option will find new deltas with
1405+
the `-f` option to linkgit:git-repack[1]. For the reasons elaborated
1406+
on above using `--aggressive` after a fast-import is one of the few
1407+
cases where it's known to be worthwhile.
14011408

14021409
MEMORY UTILIZATION
14031410
------------------

Documentation/git-gc.txt

Lines changed: 46 additions & 96 deletions
Original file line numberDiff line numberDiff line change
@@ -20,17 +20,16 @@ created from prior invocations of 'git add', packing refs, pruning
2020
reflog, rerere metadata or stale working trees. May also update ancillary
2121
indexes such as the commit-graph.
2222

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.
2627

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.
3433

3534
OPTIONS
3635
-------
@@ -40,35 +39,17 @@ OPTIONS
4039
space utilization and performance. This option will cause
4140
'git gc' to more aggressively optimize the repository at the expense
4241
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.
4543

4644
--auto::
4745
With this option, 'git gc' checks whether any housekeeping is
4846
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.
5847
+
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.
7050
+
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
7253
other housekeeping tasks (e.g. rerere, working trees, reflog...) will
7354
be performed as well.
7455

@@ -96,69 +77,39 @@ be performed as well.
9677
`.keep` files are consolidated into a single pack. When this
9778
option is used, `gc.bigPackThreshold` is ignored.
9879

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+
99106
CONFIGURATION
100107
-------------
101108

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]:
161111

112+
include::config/gc.txt[]
162113

163114
NOTES
164115
-----
@@ -168,8 +119,8 @@ anywhere in your repository. In
168119
particular, it will keep not only objects referenced by your current set
169120
of branches and tags, but also objects referenced by the index,
170121
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.
173124
If you are expecting some objects to be deleted and they aren't, check
174125
all of those locations and decide whether it makes sense in your case to
175126
remove those references.
@@ -190,8 +141,7 @@ mitigate this problem:
190141

191142
However, these features fall short of a complete solution, so users who
192143
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).
195145

196146
HOOKS
197147
-----

0 commit comments

Comments
 (0)