1GIT-CAT-FILE(1)                   Git Manual                   GIT-CAT-FILE(1)
2
3
4

NAME

6       git-cat-file - Provide content or type and size information for
7       repository objects
8

SYNOPSIS

10       git cat-file <type> <object>
11       git cat-file (-e | -p) <object>
12       git cat-file (-t | -s) [--allow-unknown-type] <object>
13       git cat-file (--batch | --batch-check | --batch-command) [--batch-all-objects]
14                    [--buffer] [--follow-symlinks] [--unordered]
15                    [--textconv | --filters] [-z]
16       git cat-file (--textconv | --filters)
17                    [<rev>:<path|tree-ish> | --path=<path|tree-ish> <rev>]
18

DESCRIPTION

20       In its first form, the command provides the content or the type of an
21       object in the repository. The type is required unless -t or -p is used
22       to find the object type, or -s is used to find the object size, or
23       --textconv or --filters is used (which imply type "blob").
24
25       In the second form, a list of objects (separated by linefeeds) is
26       provided on stdin, and the SHA-1, type, and size of each object is
27       printed on stdout. The output format can be overridden using the
28       optional <format> argument. If either --textconv or --filters was
29       specified, the input is expected to list the object names followed by
30       the path name, separated by a single whitespace, so that the
31       appropriate drivers can be determined.
32

OPTIONS

34       <object>
35           The name of the object to show. For a more complete list of ways to
36           spell object names, see the "SPECIFYING REVISIONS" section in
37           gitrevisions(7).
38
39       -t
40           Instead of the content, show the object type identified by
41           <object>.
42
43       -s
44           Instead of the content, show the object size identified by
45           <object>.
46
47       -e
48           Exit with zero status if <object> exists and is a valid object. If
49           <object> is of an invalid format exit with non-zero and emits an
50           error on stderr.
51
52       -p
53           Pretty-print the contents of <object> based on its type.
54
55       <type>
56           Typically this matches the real type of <object> but asking for a
57           type that can trivially be dereferenced from the given <object> is
58           also permitted. An example is to ask for a "tree" with <object>
59           being a commit object that contains it, or to ask for a "blob" with
60           <object> being a tag object that points at it.
61
62       --[no-]mailmap, --[no-]use-mailmap
63           Use mailmap file to map author, committer and tagger names and
64           email addresses to canonical real names and email addresses. See
65           git-shortlog(1).
66
67       --textconv
68           Show the content as transformed by a textconv filter. In this case,
69           <object> has to be of the form <tree-ish>:<path>, or :<path> in
70           order to apply the filter to the content recorded in the index at
71           <path>.
72
73       --filters
74           Show the content as converted by the filters configured in the
75           current working tree for the given <path> (i.e. smudge filters,
76           end-of-line conversion, etc). In this case, <object> has to be of
77           the form <tree-ish>:<path>, or :<path>.
78
79       --path=<path>
80           For use with --textconv or --filters, to allow specifying an object
81           name and a path separately, e.g. when it is difficult to figure out
82           the revision from which the blob came.
83
84       --batch, --batch=<format>
85           Print object information and contents for each object provided on
86           stdin. May not be combined with any other options or arguments
87           except --textconv or --filters, in which case the input lines also
88           need to specify the path, separated by whitespace. See the section
89           BATCH OUTPUT below for details.
90
91       --batch-check, --batch-check=<format>
92           Print object information for each object provided on stdin. May not
93           be combined with any other options or arguments except --textconv
94           or --filters, in which case the input lines also need to specify
95           the path, separated by whitespace. See the section BATCH OUTPUT
96           below for details.
97
98       --batch-command, --batch-command=<format>
99           Enter a command mode that reads commands and arguments from stdin.
100           May only be combined with --buffer, --textconv or --filters. In the
101           case of --textconv or --filters, the input lines also need to
102           specify the path, separated by whitespace. See the section BATCH
103           OUTPUT below for details.
104
105           --batch-command recognizes the following commands:
106
107           contents <object>
108               Print object contents for object reference <object>. This
109               corresponds to the output of --batch.
110
111           info <object>
112               Print object info for object reference <object>. This
113               corresponds to the output of --batch-check.
114
115           flush
116               Used with --buffer to execute all preceding commands that were
117               issued since the beginning or since the last flush was issued.
118               When --buffer is used, no output will come until a flush is
119               issued. When --buffer is not used, commands are flushed each
120               time without issuing flush.
121
122       --batch-all-objects
123           Instead of reading a list of objects on stdin, perform the
124           requested batch operation on all objects in the repository and any
125           alternate object stores (not just reachable objects). Requires
126           --batch or --batch-check be specified. By default, the objects are
127           visited in order sorted by their hashes; see also --unordered
128           below. Objects are presented as-is, without respecting the
129           "replace" mechanism of git-replace(1).
130
131       --buffer
132           Normally batch output is flushed after each object is output, so
133           that a process can interactively read and write from cat-file. With
134           this option, the output uses normal stdio buffering; this is much
135           more efficient when invoking --batch-check or --batch-command on a
136           large number of objects.
137
138       --unordered
139           When --batch-all-objects is in use, visit objects in an order which
140           may be more efficient for accessing the object contents than hash
141           order. The exact details of the order are unspecified, but if you
142           do not require a specific order, this should generally result in
143           faster output, especially with --batch. Note that cat-file will
144           still show each object only once, even if it is stored multiple
145           times in the repository.
146
147       --allow-unknown-type
148           Allow -s or -t to query broken/corrupt objects of unknown type.
149
150       --follow-symlinks
151           With --batch or --batch-check, follow symlinks inside the
152           repository when requesting objects with extended SHA-1 expressions
153           of the form tree-ish:path-in-tree. Instead of providing output
154           about the link itself, provide output about the linked-to object.
155           If a symlink points outside the tree-ish (e.g. a link to /foo or a
156           root-level link to ../foo), the portion of the link which is
157           outside the tree will be printed.
158
159           This option does not (currently) work correctly when an object in
160           the index is specified (e.g.  :link instead of HEAD:link) rather
161           than one in the tree.
162
163           This option cannot (currently) be used unless --batch or
164           --batch-check is used.
165
166           For example, consider a git repository containing:
167
168               f: a file containing "hello\n"
169               link: a symlink to f
170               dir/link: a symlink to ../f
171               plink: a symlink to ../f
172               alink: a symlink to /etc/passwd
173
174           For a regular file f, echo HEAD:f | git cat-file --batch would
175           print
176
177               ce013625030ba8dba906f756967f9e9ca394464a blob 6
178
179           And echo HEAD:link | git cat-file --batch --follow-symlinks would
180           print the same thing, as would HEAD:dir/link, as they both point at
181           HEAD:f.
182
183           Without --follow-symlinks, these would print data about the symlink
184           itself. In the case of HEAD:link, you would see
185
186               4d1ae35ba2c8ec712fa2a379db44ad639ca277bd blob 1
187
188           Both plink and alink point outside the tree, so they would
189           respectively print:
190
191               symlink 4
192               ../f
193
194               symlink 11
195               /etc/passwd
196
197       -z
198           Only meaningful with --batch, --batch-check, or --batch-command;
199           input is NUL-delimited instead of newline-delimited.
200

OUTPUT

202       If -t is specified, one of the <type>.
203
204       If -s is specified, the size of the <object> in bytes.
205
206       If -e is specified, no output, unless the <object> is malformed.
207
208       If -p is specified, the contents of <object> are pretty-printed.
209
210       If <type> is specified, the raw (though uncompressed) contents of the
211       <object> will be returned.
212

BATCH OUTPUT

214       If --batch or --batch-check is given, cat-file will read objects from
215       stdin, one per line, and print information about them. By default, the
216       whole line is considered as an object, as if it were fed to git-rev-
217       parse(1).
218
219       When --batch-command is given, cat-file will read commands from stdin,
220       one per line, and print information based on the command given. With
221       --batch-command, the info command followed by an object will print
222       information about the object the same way --batch-check would, and the
223       contents command followed by an object prints contents in the same way
224       --batch would.
225
226       You can specify the information shown for each object by using a custom
227       <format>. The <format> is copied literally to stdout for each object,
228       with placeholders of the form %(atom) expanded, followed by a newline.
229       The available atoms are:
230
231       objectname
232           The full hex representation of the object name.
233
234       objecttype
235           The type of the object (the same as cat-file -t reports).
236
237       objectsize
238           The size, in bytes, of the object (the same as cat-file -s
239           reports).
240
241       objectsize:disk
242           The size, in bytes, that the object takes up on disk. See the note
243           about on-disk sizes in the CAVEATS section below.
244
245       deltabase
246           If the object is stored as a delta on-disk, this expands to the
247           full hex representation of the delta base object name. Otherwise,
248           expands to the null OID (all zeroes). See CAVEATS below.
249
250       rest
251           If this atom is used in the output string, input lines are split at
252           the first whitespace boundary. All characters before that
253           whitespace are considered to be the object name; characters after
254           that first run of whitespace (i.e., the "rest" of the line) are
255           output in place of the %(rest) atom.
256
257       If no format is specified, the default format is %(objectname)
258       %(objecttype) %(objectsize).
259
260       If --batch is specified, or if --batch-command is used with the
261       contents command, the object information is followed by the object
262       contents (consisting of %(objectsize) bytes), followed by a newline.
263
264       For example, --batch without a custom format would produce:
265
266           <oid> SP <type> SP <size> LF
267           <contents> LF
268
269       Whereas --batch-check='%(objectname) %(objecttype)' would produce:
270
271           <oid> SP <type> LF
272
273       If a name is specified on stdin that cannot be resolved to an object in
274       the repository, then cat-file will ignore any custom format and print:
275
276           <object> SP missing LF
277
278       If a name is specified that might refer to more than one object (an
279       ambiguous short sha), then cat-file will ignore any custom format and
280       print:
281
282           <object> SP ambiguous LF
283
284       If --follow-symlinks is used, and a symlink in the repository points
285       outside the repository, then cat-file will ignore any custom format and
286       print:
287
288           symlink SP <size> LF
289           <symlink> LF
290
291       The symlink will either be absolute (beginning with a /), or relative
292       to the tree root. For instance, if dir/link points to ../../foo, then
293       <symlink> will be ../foo. <size> is the size of the symlink in bytes.
294
295       If --follow-symlinks is used, the following error messages will be
296       displayed:
297
298           <object> SP missing LF
299
300       is printed when the initial symlink requested does not exist.
301
302           dangling SP <size> LF
303           <object> LF
304
305       is printed when the initial symlink exists, but something that it
306       (transitive-of) points to does not.
307
308           loop SP <size> LF
309           <object> LF
310
311       is printed for symlink loops (or any symlinks that require more than 40
312       link resolutions to resolve).
313
314           notdir SP <size> LF
315           <object> LF
316
317       is printed when, during symlink resolution, a file is used as a
318       directory name.
319

CAVEATS

321       Note that the sizes of objects on disk are reported accurately, but
322       care should be taken in drawing conclusions about which refs or objects
323       are responsible for disk usage. The size of a packed non-delta object
324       may be much larger than the size of objects which delta against it, but
325       the choice of which object is the base and which is the delta is
326       arbitrary and is subject to change during a repack.
327
328       Note also that multiple copies of an object may be present in the
329       object database; in this case, it is undefined which copy’s size or
330       delta base will be reported.
331

GIT

333       Part of the git(1) suite
334
335
336
337Git 2.39.1                        2023-01-13                   GIT-CAT-FILE(1)
Impressum