freshlybakedca.ke
Git fork
1git-repack(1)
2=============
3
4NAME
5----
6git-repack - Pack unpacked objects in a repository
7
8
9SYNOPSIS
10--------
11[verse]
12'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [-b] [-m]
13 [--window=<n>] [--depth=<n>] [--threads=<n>] [--keep-pack=<pack-name>]
14 [--write-midx] [--name-hash-version=<n>] [--path-walk]
15
16DESCRIPTION
17-----------
18
19This command is used to combine all objects that do not currently
20reside in a "pack", into a pack. It can also be used to re-organize
21existing packs into a single, more efficient pack.
22
23A pack is a collection of objects, individually compressed, with
24delta compression applied, stored in a single file, with an
25associated index file.
26
27Packs are used to reduce the load on mirror systems, backup
28engines, disk storage, etc.
29
30OPTIONS
31-------
32
33-a::
34 Instead of incrementally packing the unpacked objects,
35 pack everything referenced into a single pack.
36 Especially useful when packing a repository that is used
37 for private development. Use
38 with `-d`. This will clean up the objects that `git prune`
39 leaves behind, but `git fsck --full --dangling` shows as
40 dangling.
41+
42Note that users fetching over dumb protocols will have to fetch the
43whole new pack in order to get any contained object, no matter how many
44other objects in that pack they already have locally.
45+
46Promisor packfiles are repacked separately: if there are packfiles that
47have an associated ".promisor" file, these packfiles will be repacked
48into another separate pack, and an empty ".promisor" file corresponding
49to the new separate pack will be written.
50
51-A::
52 Same as `-a`, unless `-d` is used. Then any unreachable
53 objects in a previous pack become loose, unpacked objects,
54 instead of being left in the old pack. Unreachable objects
55 are never intentionally added to a pack, even when repacking.
56 This option prevents unreachable objects from being immediately
57 deleted by way of being left in the old pack and then
58 removed. Instead, the loose unreachable objects
59 will be pruned according to normal expiry rules
60 with the next 'git gc' invocation. See linkgit:git-gc[1].
61
62-d::
63 After packing, if the newly created packs make some
64 existing packs redundant, remove the redundant packs.
65 Also run 'git prune-packed' to remove redundant
66 loose object files.
67
68--cruft::
69 Same as `-a`, unless `-d` is used. Then any unreachable objects
70 are packed into a separate cruft pack. Unreachable objects can
71 be pruned using the normal expiry rules with the next `git gc`
72 invocation (see linkgit:git-gc[1]). Incompatible with `-k`.
73
74--cruft-expiration=<approxidate>::
75 Expire unreachable objects older than `<approxidate>`
76 immediately instead of waiting for the next `git gc` invocation.
77 Only useful with `--cruft -d`.
78
79--max-cruft-size=<n>::
80 Overrides `--max-pack-size` for cruft packs. Inherits the value of
81 `--max-pack-size` (if any) by default. See the documentation for
82 `--max-pack-size` for more details.
83
84--combine-cruft-below-size=<n>::
85 When generating cruft packs without pruning, only repack
86 existing cruft packs whose size is strictly less than `<n>`,
87 where `<n>` represents a number of bytes, which can optionally
88 be suffixed with "k", "m", or "g". Cruft packs whose size is
89 greater than or equal to `<n>` are left as-is and not repacked.
90 Useful when you want to avoid repacking large cruft pack(s) in
91 repositories that have many and/or large unreachable objects.
92
93--expire-to=<dir>::
94 Write a cruft pack containing pruned objects (if any) to the
95 directory `<dir>`. This option is useful for keeping a copy of
96 any pruned objects in a separate directory as a backup. Only
97 useful with `--cruft -d`.
98
99-l::
100 Pass the `--local` option to 'git pack-objects'. See
101 linkgit:git-pack-objects[1].
102
103-f::
104 Pass the `--no-reuse-delta` option to `git-pack-objects`, see
105 linkgit:git-pack-objects[1].
106
107-F::
108 Pass the `--no-reuse-object` option to `git-pack-objects`, see
109 linkgit:git-pack-objects[1].
110
111-q::
112--quiet::
113 Show no progress over the standard error stream and pass the `-q`
114 option to 'git pack-objects'. See linkgit:git-pack-objects[1].
115
116-n::
117 Do not update the server information with
118 'git update-server-info'. This option skips
119 updating local catalog files needed to publish
120 this repository (or a direct copy of it)
121 over HTTP or FTP. See linkgit:git-update-server-info[1].
122
123--window=<n>::
124--depth=<n>::
125 These two options affect how the objects contained in the pack are
126 stored using delta compression. The objects are first internally
127 sorted by type, size and optionally names and compared against the
128 other objects within `--window` to see if using delta compression saves
129 space. `--depth` limits the maximum delta depth; making it too deep
130 affects the performance on the unpacker side, because delta data needs
131 to be applied that many times to get to the necessary object.
132+
133The default value for --window is 10 and --depth is 50. The maximum
134depth is 4095.
135
136--threads=<n>::
137 This option is passed through to `git pack-objects`.
138
139--window-memory=<n>::
140 This option provides an additional limit on top of `--window`;
141 the window size will dynamically scale down so as to not take
142 up more than '<n>' bytes in memory. This is useful in
143 repositories with a mix of large and small objects to not run
144 out of memory with a large window, but still be able to take
145 advantage of the large window for the smaller objects. The
146 size can be suffixed with "k", "m", or "g".
147 `--window-memory=0` makes memory usage unlimited. The default
148 is taken from the `pack.windowMemory` configuration variable.
149 Note that the actual memory usage will be the limit multiplied
150 by the number of threads used by linkgit:git-pack-objects[1].
151
152--max-pack-size=<n>::
153 Maximum size of each output pack file. The size can be suffixed with
154 "k", "m", or "g". The minimum size allowed is limited to 1 MiB.
155 If specified, multiple packfiles may be created, which also
156 prevents the creation of a bitmap index.
157 The default is unlimited, unless the config variable
158 `pack.packSizeLimit` is set. Note that this option may result in
159 a larger and slower repository; see the discussion in
160 `pack.packSizeLimit`.
161
162--filter=<filter-spec>::
163 Remove objects matching the filter specification from the
164 resulting packfile and put them into a separate packfile. Note
165 that objects used in the working directory are not filtered
166 out. So for the split to fully work, it's best to perform it
167 in a bare repo and to use the `-a` and `-d` options along with
168 this option. Also `--no-write-bitmap-index` (or the
169 `repack.writebitmaps` config option set to `false`) should be
170 used otherwise writing bitmap index will fail, as it supposes
171 a single packfile containing all the objects. See
172 linkgit:git-rev-list[1] for valid `<filter-spec>` forms.
173
174--filter-to=<dir>::
175 Write the pack containing filtered out objects to the
176 directory `<dir>`. Only useful with `--filter`. This can be
177 used for putting the pack on a separate object directory that
178 is accessed through the Git alternates mechanism. **WARNING:**
179 If the packfile containing the filtered out objects is not
180 accessible, the repo can become corrupt as it might not be
181 possible to access the objects in that packfile. See the
182 `objects` and `objects/info/alternates` sections of
183 linkgit:gitrepository-layout[5].
184
185-b::
186--write-bitmap-index::
187 Write a reachability bitmap index as part of the repack. This
188 only makes sense when used with `-a`, `-A` or `-m`, as the bitmaps
189 must be able to refer to all reachable objects. This option
190 overrides the setting of `repack.writeBitmaps`. This option
191 has no effect if multiple packfiles are created, unless writing a
192 MIDX (in which case a multi-pack bitmap is created).
193
194--pack-kept-objects::
195 Include objects in `.keep` files when repacking. Note that we
196 still do not delete `.keep` packs after `pack-objects` finishes.
197 This means that we may duplicate objects, but this makes the
198 option safe to use when there are concurrent pushes or fetches.
199 This option is generally only useful if you are writing bitmaps
200 with `-b` or `repack.writeBitmaps`, as it ensures that the
201 bitmapped packfile has the necessary objects.
202
203--keep-pack=<pack-name>::
204 Exclude the given pack from repacking. This is the equivalent
205 of having `.keep` file on the pack. `<pack-name>` is the
206 pack file name without leading directory (e.g. `pack-123.pack`).
207 The option can be specified multiple times to keep multiple
208 packs.
209
210--unpack-unreachable=<when>::
211 When loosening unreachable objects, do not bother loosening any
212 objects older than `<when>`. This can be used to optimize out
213 the write of any objects that would be immediately pruned by
214 a follow-up `git prune`.
215
216-k::
217--keep-unreachable::
218 When used with `-ad`, any unreachable objects from existing
219 packs will be appended to the end of the packfile instead of
220 being removed. In addition, any unreachable loose objects will
221 be packed (and their loose counterparts removed).
222
223-i::
224--delta-islands::
225 Pass the `--delta-islands` option to `git-pack-objects`, see
226 linkgit:git-pack-objects[1].
227
228-g<factor>::
229--geometric=<factor>::
230 Arrange resulting pack structure so that each successive pack
231 contains at least `<factor>` times the number of objects as the
232 next-largest pack.
233+
234`git repack` ensures this by determining a "cut" of packfiles that need
235to be repacked into one in order to ensure a geometric progression. It
236picks the smallest set of packfiles such that as many of the larger
237packfiles (by count of objects contained in that pack) may be left
238intact.
239+
240Unlike other repack modes, the set of objects to pack is determined
241uniquely by the set of packs being "rolled-up"; in other words, the
242packs determined to need to be combined in order to restore a geometric
243progression.
244+
245Loose objects are implicitly included in this "roll-up", without respect to
246their reachability. This is subject to change in the future.
247+
248When writing a multi-pack bitmap, `git repack` selects the largest resulting
249pack as the preferred pack for object selection by the MIDX (see
250linkgit:git-multi-pack-index[1]).
251
252-m::
253--write-midx::
254 Write a multi-pack index (see linkgit:git-multi-pack-index[1])
255 containing the non-redundant packs.
256
257--name-hash-version=<n>::
258 Provide this argument to the underlying `git pack-objects` process.
259 See linkgit:git-pack-objects[1] for full details.
260
261--path-walk::
262 Pass the `--path-walk` option to the underlying `git pack-objects`
263 process. See linkgit:git-pack-objects[1] for full details.
264
265CONFIGURATION
266-------------
267
268Various configuration variables affect packing, see
269linkgit:git-config[1] (search for "pack" and "delta").
270
271By default, the command passes `--delta-base-offset` option to
272'git pack-objects'; this typically results in slightly smaller packs,
273but the generated packs are incompatible with versions of Git older than
274version 1.4.4. If you need to share your repository with such ancient Git
275versions, either directly or via the dumb http protocol, then you
276need to set the configuration variable `repack.UseDeltaBaseOffset` to
277"false" and repack. Access from old Git versions over the native protocol
278is unaffected by this option as the conversion is performed on the fly
279as needed in that case.
280
281Delta compression is not used on objects larger than the
282`core.bigFileThreshold` configuration variable and on files with the
283attribute `delta` set to false.
284
285SEE ALSO
286--------
287linkgit:git-pack-objects[1]
288linkgit:git-prune-packed[1]
289
290GIT
291---
292Part of the linkgit:git[1] suite