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' (-t [--allow-unknown-type]| -s [--allow-unknown-type]| -e | -p | <type> | --textconv ) <object>
  13 'git cat-file' (--batch | --batch-check) [--follow-symlinks] < <list-of-objects>
  14
  15 DESCRIPTION
  16 -----------
  17 In its first form, the command provides the content or the type of an object in
  18 the repository. The type is required unless '-t' or '-p' is used to find the
  19 object type, or '-s' is used to find the object size, or '--textconv' is used
  20 (which implies type "blob").
  21
  22 In the second form, a list of objects (separated by linefeeds) is provided on
  23 stdin, and the SHA-1, type, and size of each object is printed on stdout.
  24
  25 OPTIONS
  26 -------
  27 <object>::
  28         The name of the object to show.
  29         For a more complete list of ways to spell object names, see
  30         the "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
  31
  32 -t::
  33         Instead of the content, show the object type identified by
  34         <object>.
  35
  36 -s::
  37         Instead of the content, show the object size identified by
  38         <object>.
  39
  40 -e::
  41         Suppress all output; instead exit with zero status if <object>
  42         exists and is a valid object.
  43
  44 -p::
  45         Pretty-print the contents of <object> based on its type.
  46
  47 <type>::
  48         Typically this matches the real type of <object> but asking
  49         for a type that can trivially be dereferenced from the given
  50         <object> is also permitted.  An example is to ask for a
  51         "tree" with <object> being a commit object that contains it,
  52         or to ask for a "blob" with <object> being a tag object that
  53         points at it.
  54
  55 --textconv::
  56         Show the content as transformed by a textconv filter. In this case,
  57         <object> has be of the form <tree-ish>:<path>, or :<path> in order
  58         to apply the filter to the content recorded in the index at <path>.
  59
  60 --batch::
  61 --batch=<format>::
  62         Print object information and contents for each object provided
  63         on stdin.  May not be combined with any other options or arguments.
  64         See the section `BATCH OUTPUT` below for details.
  65
  66 --batch-check::
  67 --batch-check=<format>::
  68         Print object information for each object provided on stdin.  May
  69         not be combined with any other options or arguments.  See the
  70         section `BATCH OUTPUT` below for details.
  71
  72 --batch-all-objects::
  73         Instead of reading a list of objects on stdin, perform the
  74         requested batch operation on all objects in the repository and
  75         any alternate object stores (not just reachable objects).
  76         Requires `--batch` or `--batch-check` be specified. Note that
  77         the order of the objects is unspecified, and there may be
  78         duplicate entries.
  79
  80 --buffer::
  81         Normally batch output is flushed after each object is output, so
  82         that a process can interactively read and write from
  83         `cat-file`. With this option, the output uses normal stdio
  84         buffering; this is much more efficient when invoking
  85         `--batch-check` on a large number of objects.
  86
  87 --allow-unknown-type::
  88         Allow -s or -t to query broken/corrupt objects of unknown type.
  89
  90 --follow-symlinks::
  91         With --batch or --batch-check, follow symlinks inside the
  92         repository when requesting objects with extended SHA-1
  93         expressions of the form tree-ish:path-in-tree.  Instead of
  94         providing output about the link itself, provide output about
  95         the linked-to object.  If a symlink points outside the
  96         tree-ish (e.g. a link to /foo or a root-level link to ../foo),
  97         the portion of the link which is outside the tree will be
  98         printed.
  99 +
 100 This option does not (currently) work correctly when an object in the
 101 index is specified (e.g. `:link` instead of `HEAD:link`) rather than
 102 one in the tree.
 103 +
 104 This option cannot (currently) be used unless `--batch` or
 105 `--batch-check` is used.
 106 +
 107 For example, consider a git repository containing:
 108 +
 109 --
 110         f: a file containing "hello\n"
 111         link: a symlink to f
 112         dir/link: a symlink to ../f
 113         plink: a symlink to ../f
 114         alink: a symlink to /etc/passwd
 115 --
 116 +
 117 For a regular file `f`, `echo HEAD:f | git cat-file --batch` would print
 118 +
 119 --
 120         ce013625030ba8dba906f756967f9e9ca394464a blob 6
 121 --
 122 +
 123 And `echo HEAD:link | git cat-file --batch --follow-symlinks` would
 124 print the same thing, as would `HEAD:dir/link`, as they both point at
 125 `HEAD:f`.
 126 +
 127 Without `--follow-symlinks`, these would print data about the symlink
 128 itself.  In the case of `HEAD:link`, you would see
 129 +
 130 --
 131         4d1ae35ba2c8ec712fa2a379db44ad639ca277bd blob 1
 132 --
 133 +
 134 Both `plink` and `alink` point outside the tree, so they would
 135 respectively print:
 136 +
 137 --
 138         symlink 4
 139         ../f
 140
 141         symlink 11
 142         /etc/passwd
 143 --
 144
 145
 146 OUTPUT
 147 ------
 148 If '-t' is specified, one of the <type>.
 149
 150 If '-s' is specified, the size of the <object> in bytes.
 151
 152 If '-e' is specified, no output.
 153
 154 If '-p' is specified, the contents of <object> are pretty-printed.
 155
 156 If <type> is specified, the raw (though uncompressed) contents of the <object>
 157 will be returned.
 158
 159 BATCH OUTPUT
 160 ------------
 161
 162 If `--batch` or `--batch-check` is given, `cat-file` will read objects
 163 from stdin, one per line, and print information about them. By default,
 164 the whole line is considered as an object, as if it were fed to
 165 linkgit:git-rev-parse[1].
 166
 167 You can specify the information shown for each object by using a custom
 168 `<format>`. The `<format>` is copied literally to stdout for each
 169 object, with placeholders of the form `%(atom)` expanded, followed by a
 170 newline. The available atoms are:
 171
 172 `objectname`::
 173         The 40-hex object name of the object.
 174
 175 `objecttype`::
 176         The type of of the object (the same as `cat-file -t` reports).
 177
 178 `objectsize`::
 179         The size, in bytes, of the object (the same as `cat-file -s`
 180         reports).
 181
 182 `objectsize:disk`::
 183         The size, in bytes, that the object takes up on disk. See the
 184         note about on-disk sizes in the `CAVEATS` section below.
 185
 186 `deltabase`::
 187         If the object is stored as a delta on-disk, this expands to the
 188         40-hex sha1 of the delta base object. Otherwise, expands to the
 189         null sha1 (40 zeroes). See `CAVEATS` below.
 190
 191 `rest`::
 192         If this atom is used in the output string, input lines are split
 193         at the first whitespace boundary. All characters before that
 194         whitespace are considered to be the object name; characters
 195         after that first run of whitespace (i.e., the "rest" of the
 196         line) are output in place of the `%(rest)` atom.
 197
 198 If no format is specified, the default format is `%(objectname)
 199 %(objecttype) %(objectsize)`.
 200
 201 If `--batch` is specified, the object information is followed by the
 202 object contents (consisting of `%(objectsize)` bytes), followed by a
 203 newline.
 204
 205 For example, `--batch` without a custom format would produce:
 206
 207 ------------
 208 <sha1> SP <type> SP <size> LF
 209 <contents> LF
 210 ------------
 211
 212 Whereas `--batch-check='%(objectname) %(objecttype)'` would produce:
 213
 214 ------------
 215 <sha1> SP <type> LF
 216 ------------
 217
 218 If a name is specified on stdin that cannot be resolved to an object in
 219 the repository, then `cat-file` will ignore any custom format and print:
 220
 221 ------------
 222 <object> SP missing LF
 223 ------------
 224
 225 If --follow-symlinks is used, and a symlink in the repository points
 226 outside the repository, then `cat-file` will ignore any custom format
 227 and print:
 228
 229 ------------
 230 symlink SP <size> LF
 231 <symlink> LF
 232 ------------
 233
 234 The symlink will either be absolute (beginning with a /), or relative
 235 to the tree root.  For instance, if dir/link points to ../../foo, then
 236 <symlink> will be ../foo.  <size> is the size of the symlink in bytes.
 237
 238 If --follow-symlinks is used, the following error messages will be
 239 displayed:
 240
 241 ------------
 242 <object> SP missing LF
 243 ------------
 244 is printed when the initial symlink requested does not exist.
 245
 246 ------------
 247 dangling SP <size> LF
 248 <object> LF
 249 ------------
 250 is printed when the initial symlink exists, but something that
 251 it (transitive-of) points to does not.
 252
 253 ------------
 254 loop SP <size> LF
 255 <object> LF
 256 ------------
 257 is printed for symlink loops (or any symlinks that
 258 require more than 40 link resolutions to resolve).
 259
 260 ------------
 261 notdir SP <size> LF
 262 <object> LF
 263 ------------
 264 is printed when, during symlink resolution, a file is used as a
 265 directory name.
 266
 267 CAVEATS
 268 -------
 269
 270 Note that the sizes of objects on disk are reported accurately, but care
 271 should be taken in drawing conclusions about which refs or objects are
 272 responsible for disk usage. The size of a packed non-delta object may be
 273 much larger than the size of objects which delta against it, but the
 274 choice of which object is the base and which is the delta is arbitrary
 275 and is subject to change during a repack.
 276
 277 Note also that multiple copies of an object may be present in the object
 278 database; in this case, it is undefined which copy's size or delta base
 279 will be reported.
 280
 281 GIT
 282 ---
 283 Part of the linkgit:git[1] suite