1GIT-PACK-OBJECTS(1) Git Manual GIT-PACK-OBJECTS(1)
2
6 git-pack-objects - Create a packed archive of objects
7
9 git pack-objects [-q | --progress | --all-progress] [--all-progress-implied]
10 [--no-reuse-delta] [--delta-base-offset] [--non-empty]
11 [--local] [--incremental] [--window=<n>] [--depth=<n>]
12 [--revs [--unpacked | --all]] [--stdout | base-name]
13 [--keep-true-parents] < object-list
14
17 Reads list of objects from the standard input, and writes a packed
18 archive with specified base-name, or to the standard output.
19 A packed archive is an efficient way to transfer a set of objects
21 between two repositories as well as an access efficient archival
22 format. In a packed archive, an object is either stored as a compressed
23 whole or as a difference from some other object. The latter is often
24 called a delta.
25 The packed archive format (.pack) is designed to be self-contained so
27 that it can be unpacked without any further information. Therefore,
28 each object that a delta depends upon must be present within the pack.
29 A pack index file (.idx) is generated for fast, random access to the
31 objects in the pack. Placing both the index file (.idx) and the packed
32 archive (.pack) in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
33 any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES) enables
34 Git to read from the pack archive.
35 The git unpack-objects command can read the packed archive and expand
37 the objects contained in the pack into "one-file one-object" format;
38 this is typically done by the smart-pull commands when a pack is
39 created on-the-fly for efficient network transport by their peers.
40
42 base-name
43 Write into a pair of files (.pack and .idx), using <base-name> to
44 determine the name of the created file. When this option is used,
45 the two files are written in <base-name>-<SHA-1>.{pack,idx} files.
46 <SHA-1> is a hash of the sorted object names to make the resulting
47 filename based on the pack content, and written to the standard
48 output of the command.
49 --stdout
51 Write the pack contents (what would have been written to .pack
52 file) out to the standard output.
53 --revs
55 Read the revision arguments from the standard input, instead of
56 individual object names. The revision arguments are processed the
57 same way as git rev-list with the --objects flag uses its commit
58 arguments to build the list of objects it outputs. The objects on
59 the resulting list are packed.
60 --unpacked
62 This implies --revs. When processing the list of revision arguments
63 read from the standard input, limit the objects packed to those
64 that are not already packed.
65 --all
67 This implies --revs. In addition to the list of revision arguments
68 read from the standard input, pretend as if all refs under refs/
69 are specified to be included.
70 --include-tag
72 Include unasked-for annotated tags if the object they reference was
73 included in the resulting packfile. This can be useful to send new
74 tags to native Git clients.
75 --window=<n>, --depth=<n>
77 These two options affect how the objects contained in the pack are
78 stored using delta compression. The objects are first internally
79 sorted by type, size and optionally names and compared against the
80 other objects within --window to see if using delta compression
81 saves space. --depth limits the maximum delta depth; making it too
82 deep affects the performance on the unpacker side, because delta
83 data needs to be applied that many times to get to the necessary
84 object. The default value for --window is 10 and --depth is 50.
85 --window-memory=<n>
87 This option provides an additional limit on top of --window; the
88 window size will dynamically scale down so as to not take up more
89 than <n> bytes in memory. This is useful in repositories with a mix
90 of large and small objects to not run out of memory with a large
91 window, but still be able to take advantage of the large window for
92 the smaller objects. The size can be suffixed with "k", "m", or
93 "g". --window-memory=0 makes memory usage unlimited, which is the
94 default.
95 --max-pack-size=<n>
97 Maximum size of each output pack file. The size can be suffixed
98 with "k", "m", or "g". The minimum size allowed is limited to 1
99 MiB. If specified, multiple packfiles may be created. The default
100 is unlimited, unless the config variable pack.packSizeLimit is set.
101 --honor-pack-keep
103 This flag causes an object already in a local pack that has a .keep
104 file to be ignored, even if it would have otherwise been packed.
105 --incremental
107 This flag causes an object already in a pack to be ignored even if
108 it would have otherwise been packed.
109 --local
111 This flag causes an object that is borrowed from an alternate
112 object store to be ignored even if it would have otherwise been
113 packed.
114 --non-empty
116 Only create a packed archive if it would contain at least one
117 object.
118 --progress
120 Progress status is reported on the standard error stream by default
121 when it is attached to a terminal, unless -q is specified. This
122 flag forces progress status even if the standard error stream is
123 not directed to a terminal.
124 --all-progress
126 When --stdout is specified then progress report is displayed during
127 the object count and compression phases but inhibited during the
128 write-out phase. The reason is that in some cases the output stream
129 is directly linked to another command which may wish to display
130 progress status of its own as it processes incoming pack data. This
131 flag is like --progress except that it forces progress report for
132 the write-out phase as well even if --stdout is used.
133 --all-progress-implied
135 This is used to imply --all-progress whenever progress display is
136 activated. Unlike --all-progress this flag doesn’t actually force
137 any progress display by itself.
138 -q
140 This flag makes the command not to report its progress on the
141 standard error stream.
142 --no-reuse-delta
144 When creating a packed archive in a repository that has existing
145 packs, the command reuses existing deltas. This sometimes results
146 in a slightly suboptimal pack. This flag tells the command not to
147 reuse existing deltas but compute them from scratch.
148 --no-reuse-object
150 This flag tells the command not to reuse existing object data at
151 all, including non deltified object, forcing recompression of
152 everything. This implies --no-reuse-delta. Useful only in the
153 obscure case where wholesale enforcement of a different compression
154 level on the packed data is desired.
155 --compression=<n>
157 Specifies compression level for newly-compressed data in the
158 generated pack. If not specified, pack compression level is
159 determined first by pack.compression, then by core.compression, and
160 defaults to -1, the zlib default, if neither is set. Add
161 --no-reuse-object if you want to force a uniform compression level
162 on all data no matter the source.
163 --thin
165 Create a "thin" pack by omitting the common objects between a
166 sender and a receiver in order to reduce network transfer. This
167 option only makes sense in conjunction with --stdout.
168 Note: A thin pack violates the packed archive format by omitting
170 required objects and is thus unusable by Git without making it
171 self-contained. Use git index-pack --fix-thin (see git-index-
172 pack(1)) to restore the self-contained property.
173 --delta-base-offset
175 A packed archive can express the base object of a delta as either a
176 20-byte object name or as an offset in the stream, but ancient
177 versions of Git don’t understand the latter. By default, git
178 pack-objects only uses the former format for better compatibility.
179 This option allows the command to use the latter format for
180 compactness. Depending on the average delta chain length, this
181 option typically shrinks the resulting packfile by 3-5 per-cent.
182 Note: Porcelain commands such as git gc (see git-gc(1)), git repack
184 (see git-repack(1)) pass this option by default in modern Git when
185 they put objects in your repository into pack files. So does git
186 bundle (see git-bundle(1)) when it creates a bundle.
187 --threads=<n>
189 Specifies the number of threads to spawn when searching for best
190 delta matches. This requires that pack-objects be compiled with
191 pthreads otherwise this option is ignored with a warning. This is
192 meant to reduce packing time on multiprocessor machines. The
193 required amount of memory for the delta search window is however
194 multiplied by the number of threads. Specifying 0 will cause Git to
195 auto-detect the number of CPU’s and set the number of threads
196 accordingly.
197 --index-version=<version>[,<offset>]
199 This is intended to be used by the test suite only. It allows to
200 force the version for the generated pack index, and to force 64-bit
201 index entries on objects located above the given offset.
202 --keep-true-parents
204 With this option, parents that are hidden by grafts are packed
205 nevertheless.
206
208 git-rev-list(1) git-repack(1) git-prune-packed(1)
209
211 Part of the git(1) suite
212Git 1.8.3.1 11/19/2018 GIT-PACK-OBJECTS(1)