Documentation/git-cat-file.txt

   1 git-cat-file(1)
   2 ===============
   3
   4 NAME
   5 ----
   6 git-cat-file - Provide content or type and size information for repository objects
   7
   8
   9 SYNOPSIS
  10 --------
  11 [verse]
  12 'git cat-file' <type> <object>
  13 'git cat-file' (-e | -p) <object>
  14 'git cat-file' (-t | -s) [--allow-unknown-type] <object>
  15 'git cat-file' (--batch | --batch-check | --batch-command) [--batch-all-objects]
  16              [--buffer] [--follow-symlinks] [--unordered]
  17              [--textconv | --filters] [-z]
  18 'git cat-file' (--textconv | --filters)
  19              [<rev>:<path|tree-ish> | --path=<path|tree-ish> <rev>]
  20
  21 DESCRIPTION
  22 -----------
  23 In its first form, the command provides the content or the type of an object in
  24 the repository. The type is required unless `-t` or `-p` is used to find the
  25 object type, or `-s` is used to find the object size, or `--textconv` or
  26 `--filters` is used (which imply type "blob").
  27
  28 In the second form, a list of objects (separated by linefeeds) is provided on
  29 stdin, and the SHA-1, type, and size of each object is printed on stdout. The
  30 output format can be overridden using the optional `<format>` argument. If
  31 either `--textconv` or `--filters` was specified, the input is expected to
  32 list the object names followed by the path name, separated by a single
  33 whitespace, so that the appropriate drivers can be determined.
  34
  35 OPTIONS
  36 -------
  37 <object>::
  38         The name of the object to show.
  39         For a more complete list of ways to spell object names, see
  40         the "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
  41
  42 -t::
  43         Instead of the content, show the object type identified by
  44         `<object>`.
  45
  46 -s::
  47         Instead of the content, show the object size identified by
  48         `<object>`. If used with `--use-mailmap` option, will show
  49         the size of updated object after replacing idents using the
  50         mailmap mechanism.
  51
  52 -e::
  53         Exit with zero status if `<object>` exists and is a valid
  54         object. If `<object>` is of an invalid format exit with non-zero and
  55         emits an error on stderr.
  56
  57 -p::
  58         Pretty-print the contents of `<object>` based on its type.
  59
  60 <type>::
  61         Typically this matches the real type of `<object>` but asking
  62         for a type that can trivially be dereferenced from the given
  63         `<object>` is also permitted.  An example is to ask for a
  64         "tree" with `<object>` being a commit object that contains it,
  65         or to ask for a "blob" with `<object>` being a tag object that
  66         points at it.
  67
  68 --[no-]mailmap::
  69 --[no-]use-mailmap::
  70        Use mailmap file to map author, committer and tagger names
  71        and email addresses to canonical real names and email addresses.
  72        See linkgit:git-shortlog[1].
  73
  74 --textconv::
  75         Show the content as transformed by a textconv filter. In this case,
  76         `<object>` has to be of the form `<tree-ish>:<path>`, or `:<path>` in
  77         order to apply the filter to the content recorded in the index at
  78         `<path>`.
  79
  80 --filters::
  81         Show the content as converted by the filters configured in
  82         the current working tree for the given `<path>` (i.e. smudge filters,
  83         end-of-line conversion, etc). In this case, `<object>` has to be of
  84         the form `<tree-ish>:<path>`, or `:<path>`.
  85
  86 --path=<path>::
  87         For use with `--textconv` or `--filters`, to allow specifying an object
  88         name and a path separately, e.g. when it is difficult to figure out
  89         the revision from which the blob came.
  90
  91 --batch::
  92 --batch=<format>::
  93         Print object information and contents for each object provided
  94         on stdin. May not be combined with any other options or arguments
  95         except `--textconv`, `--filters`, or `--use-mailmap`.
  96         +
  97         * When used with `--textconv` or `--filters`, the input lines
  98           must specify the path, separated by whitespace. See the section
  99           `BATCH OUTPUT` below for details.
 100         +
 101         * When used with `--use-mailmap`, for commit and tag objects, the
 102           contents part of the output shows the identities replaced using the
 103           mailmap mechanism, while the information part of the output shows
 104           the size of the object as if it actually recorded the replacement
 105           identities.
 106
 107 --batch-check::
 108 --batch-check=<format>::
 109         Print object information for each object provided on stdin. May not be
 110         combined with any other options or arguments except `--textconv`, `--filters`
 111         or `--use-mailmap`.
 112         +
 113         * When used with `--textconv` or `--filters`, the input lines must
 114          specify the path, separated by whitespace. See the section
 115          `BATCH OUTPUT` below for details.
 116         +
 117         * When used with `--use-mailmap`, for commit and tag objects, the
 118           printed object information shows the size of the object as if the
 119           identities recorded in it were replaced by the mailmap mechanism.
 120
 121 --batch-command::
 122 --batch-command=<format>::
 123         Enter a command mode that reads commands and arguments from stdin. May
 124         only be combined with `--buffer`, `--textconv`, `--use-mailmap` or
 125         `--filters`.
 126         +
 127         * When used with `--textconv` or `--filters`, the input lines must
 128           specify the path, separated by whitespace. See the section
 129           `BATCH OUTPUT` below for details.
 130         +
 131         * When used with `--use-mailmap`, for commit and tag objects, the
 132           `contents` command shows the identities replaced using the
 133           mailmap mechanism, while the `info` command shows the size
 134           of the object as if it actually recorded the replacement
 135           identities.
 136
 137 +
 138 `--batch-command` recognizes the following commands:
 139 +
 140 --
 141 contents <object>::
 142         Print object contents for object reference `<object>`. This corresponds to
 143         the output of `--batch`.
 144
 145 info <object>::
 146         Print object info for object reference `<object>`. This corresponds to the
 147         output of `--batch-check`.
 148
 149 flush::
 150         Used with `--buffer` to execute all preceding commands that were issued
 151         since the beginning or since the last flush was issued. When `--buffer`
 152         is used, no output will come until a `flush` is issued. When `--buffer`
 153         is not used, commands are flushed each time without issuing `flush`.
 154 --
 155 +
 156
 157 --batch-all-objects::
 158         Instead of reading a list of objects on stdin, perform the
 159         requested batch operation on all objects in the repository and
 160         any alternate object stores (not just reachable objects).
 161         Requires `--batch` or `--batch-check` be specified. By default,
 162         the objects are visited in order sorted by their hashes; see
 163         also `--unordered` below. Objects are presented as-is, without
 164         respecting the "replace" mechanism of linkgit:git-replace[1].
 165
 166 --buffer::
 167         Normally batch output is flushed after each object is output, so
 168         that a process can interactively read and write from
 169         `cat-file`. With this option, the output uses normal stdio
 170         buffering; this is much more efficient when invoking
 171         `--batch-check` or `--batch-command` on a large number of objects.
 172
 173 --unordered::
 174         When `--batch-all-objects` is in use, visit objects in an
 175         order which may be more efficient for accessing the object
 176         contents than hash order. The exact details of the order are
 177         unspecified, but if you do not require a specific order, this
 178         should generally result in faster output, especially with
 179         `--batch`.  Note that `cat-file` will still show each object
 180         only once, even if it is stored multiple times in the
 181         repository.
 182
 183 --allow-unknown-type::
 184         Allow `-s` or `-t` to query broken/corrupt objects of unknown type.
 185
 186 --follow-symlinks::
 187         With `--batch` or `--batch-check`, follow symlinks inside the
 188         repository when requesting objects with extended SHA-1
 189         expressions of the form tree-ish:path-in-tree.  Instead of
 190         providing output about the link itself, provide output about
 191         the linked-to object.  If a symlink points outside the
 192         tree-ish (e.g. a link to `/foo` or a root-level link to `../foo`),
 193         the portion of the link which is outside the tree will be
 194         printed.
 195 +
 196 This option does not (currently) work correctly when an object in the
 197 index is specified (e.g. `:link` instead of `HEAD:link`) rather than
 198 one in the tree.
 199 +
 200 This option cannot (currently) be used unless `--batch` or
 201 `--batch-check` is used.
 202 +
 203 For example, consider a git repository containing:
 204 +
 205 --
 206         f: a file containing "hello\n"
 207         link: a symlink to f
 208         dir/link: a symlink to ../f
 209         plink: a symlink to ../f
 210         alink: a symlink to /etc/passwd
 211 --
 212 +
 213 For a regular file `f`, `echo HEAD:f | git cat-file --batch` would print
 214 +
 215 --
 216         ce013625030ba8dba906f756967f9e9ca394464a blob 6
 217 --
 218 +
 219 And `echo HEAD:link | git cat-file --batch --follow-symlinks` would
 220 print the same thing, as would `HEAD:dir/link`, as they both point at
 221 `HEAD:f`.
 222 +
 223 Without `--follow-symlinks`, these would print data about the symlink
 224 itself.  In the case of `HEAD:link`, you would see
 225 +
 226 --
 227         4d1ae35ba2c8ec712fa2a379db44ad639ca277bd blob 1
 228 --
 229 +
 230 Both `plink` and `alink` point outside the tree, so they would
 231 respectively print:
 232 +
 233 --
 234         symlink 4
 235         ../f
 236
 237         symlink 11
 238         /etc/passwd
 239 --
 240
 241 -z::
 242         Only meaningful with `--batch`, `--batch-check`, or
 243         `--batch-command`; input is NUL-delimited instead of
 244         newline-delimited.
 245
 246
 247 OUTPUT
 248 ------
 249 If `-t` is specified, one of the `<type>`.
 250
 251 If `-s` is specified, the size of the `<object>` in bytes.
 252
 253 If `-e` is specified, no output, unless the `<object>` is malformed.
 254
 255 If `-p` is specified, the contents of `<object>` are pretty-printed.
 256
 257 If `<type>` is specified, the raw (though uncompressed) contents of the `<object>`
 258 will be returned.
 259
 260 BATCH OUTPUT
 261 ------------
 262
 263 If `--batch` or `--batch-check` is given, `cat-file` will read objects
 264 from stdin, one per line, and print information about them. By default,
 265 the whole line is considered as an object, as if it were fed to
 266 linkgit:git-rev-parse[1].
 267
 268 When `--batch-command` is given, `cat-file` will read commands from stdin,
 269 one per line, and print information based on the command given. With
 270 `--batch-command`, the `info` command followed by an object will print
 271 information about the object the same way `--batch-check` would, and the
 272 `contents` command followed by an object prints contents in the same way
 273 `--batch` would.
 274
 275 You can specify the information shown for each object by using a custom
 276 `<format>`. The `<format>` is copied literally to stdout for each
 277 object, with placeholders of the form `%(atom)` expanded, followed by a
 278 newline. The available atoms are:
 279
 280 `objectname`::
 281         The full hex representation of the object name.
 282
 283 `objecttype`::
 284         The type of the object (the same as `cat-file -t` reports).
 285
 286 `objectsize`::
 287         The size, in bytes, of the object (the same as `cat-file -s`
 288         reports).
 289
 290 `objectsize:disk`::
 291         The size, in bytes, that the object takes up on disk. See the
 292         note about on-disk sizes in the `CAVEATS` section below.
 293
 294 `deltabase`::
 295         If the object is stored as a delta on-disk, this expands to the
 296         full hex representation of the delta base object name.
 297         Otherwise, expands to the null OID (all zeroes). See `CAVEATS`
 298         below.
 299
 300 `rest`::
 301         If this atom is used in the output string, input lines are split
 302         at the first whitespace boundary. All characters before that
 303         whitespace are considered to be the object name; characters
 304         after that first run of whitespace (i.e., the "rest" of the
 305         line) are output in place of the `%(rest)` atom.
 306
 307 If no format is specified, the default format is `%(objectname)
 308 %(objecttype) %(objectsize)`.
 309
 310 If `--batch` is specified, or if `--batch-command` is used with the `contents`
 311 command, the object information is followed by the object contents (consisting
 312 of `%(objectsize)` bytes), followed by a newline.
 313
 314 For example, `--batch` without a custom format would produce:
 315
 316 ------------
 317 <oid> SP <type> SP <size> LF
 318 <contents> LF
 319 ------------
 320
 321 Whereas `--batch-check='%(objectname) %(objecttype)'` would produce:
 322
 323 ------------
 324 <oid> SP <type> LF
 325 ------------
 326
 327 If a name is specified on stdin that cannot be resolved to an object in
 328 the repository, then `cat-file` will ignore any custom format and print:
 329
 330 ------------
 331 <object> SP missing LF
 332 ------------
 333
 334 If a name is specified that might refer to more than one object (an ambiguous short sha), then `cat-file` will ignore any custom format and print:
 335
 336 ------------
 337 <object> SP ambiguous LF
 338 ------------
 339
 340 If `--follow-symlinks` is used, and a symlink in the repository points
 341 outside the repository, then `cat-file` will ignore any custom format
 342 and print:
 343
 344 ------------
 345 symlink SP <size> LF
 346 <symlink> LF
 347 ------------
 348
 349 The symlink will either be absolute (beginning with a `/`), or relative
 350 to the tree root.  For instance, if dir/link points to `../../foo`, then
 351 `<symlink>` will be `../foo`.  `<size>` is the size of the symlink in bytes.
 352
 353 If `--follow-symlinks` is used, the following error messages will be
 354 displayed:
 355
 356 ------------
 357 <object> SP missing LF
 358 ------------
 359 is printed when the initial symlink requested does not exist.
 360
 361 ------------
 362 dangling SP <size> LF
 363 <object> LF
 364 ------------
 365 is printed when the initial symlink exists, but something that
 366 it (transitive-of) points to does not.
 367
 368 ------------
 369 loop SP <size> LF
 370 <object> LF
 371 ------------
 372 is printed for symlink loops (or any symlinks that
 373 require more than 40 link resolutions to resolve).
 374
 375 ------------
 376 notdir SP <size> LF
 377 <object> LF
 378 ------------
 379 is printed when, during symlink resolution, a file is used as a
 380 directory name.
 381
 382 CAVEATS
 383 -------
 384
 385 Note that the sizes of objects on disk are reported accurately, but care
 386 should be taken in drawing conclusions about which refs or objects are
 387 responsible for disk usage. The size of a packed non-delta object may be
 388 much larger than the size of objects which delta against it, but the
 389 choice of which object is the base and which is the delta is arbitrary
 390 and is subject to change during a repack.
 391
 392 Note also that multiple copies of an object may be present in the object
 393 database; in this case, it is undefined which copy's size or delta base
 394 will be reported.
 395
 396 GIT
 397 ---
 398 Part of the linkgit:git[1] suite