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