last flush was issued. When `--buffer`
	is used, no output will come until a `flush` is issued. When `--buffer`
	is not used, commands are flushed each time without issuing `flush`.
--
+

--batch-all-objects::
	Instead of reading a list of objects on stdin, perform the
	requested batch operation on all objects in the repository and
	any alternate object stores (not just reachable objects).
	Requires `--batch` or `--batch-check` be specified. By default,
	the objects are visited in order sorted by their hashes; see
	also `--unordered` below. Objects are presented as-is, without
	respecting the "replace" mechanism of linkgit:git-replace[1].

--buffer::
	Normally batch output is flushed after each object is output, so
	that a process can interactively read and write from
	`cat-file`. With this option, the output uses normal stdio
	buffering; this is much more efficient when invoking
	`--batch-check` or `--batch-command` on a large number of objects.

--unordered::
	When `--batch-all-objects` is in use, visit objects in an
	order which may be more efficient for accessing the object
	contents than hash order. The exact details of the order are
	unspecified, but if you do not require a specific order, this
	should generally result in faster output, especially with
	`--batch`.  Note that `cat-file` will still show each object
	only once, even if it is stored multiple times in the
	repository.

--follow-symlinks::
	With `--batch` or `--batch-check`, follow symlinks inside the
	repository when requesting objects with extended SHA-1
	expressions of the form tree-ish:path-in-tree.  Instead of
	providing output about the link itself, provide output about
	the linked-to object.  If a symlink points outside the
	tree-ish (e.g. a link to `/foo` or a root-level link to `../foo`),
	the portion of the link which is outside the tree will be
	printed.
+
This option does not (currently) work correctly when an object in the
index is specified (e.g. `:link` instead of `HEAD:link`) rather than
one in the tree.
+
This option cannot (currently) be used unless `--batch` or
`--batch-check` is used.
+
For example, consider a git repository containing:
+
--
	f: a file containing "hello\n"
	link: a symlink to f
	dir/link: a symlink to ../f
	plink: a symlink to ../f
	alink: a symlink to /etc/passwd
--
+
For a regular file `f`, `echo HEAD:f | git cat-file --batch` would print
+
--
	ce013625030ba8dba906f756967f9e9ca394464a blob 6
--
+
And `echo HEAD:link | git cat-file --batch --follow-symlinks` would
print the same thing, as would `HEAD:dir/link`, as they both point at
`HEAD:f`.
+
Without `--follow-symlinks`, these would print data about the symlink
itself.  In the case of `HEAD:link`, you would see
+
--
	4d1ae35ba2c8ec712fa2a379db44ad639ca277bd blob 1
--
+
Both `plink` and `alink` point outside the tree, so they would
respectively print:
+
--
	symlink 4
	../f

	symlink 11
	/etc/passwd
--

-Z::
	Only meaningful with `--batch`, `--batch-check`, or
	`--batch-command`; input and output is NUL-delimited instead of
	newline-delimited.

-z::
	Only meaningful with `--batch`, `--batch-check`, or
	`--batch-command`; input is NUL-delimited instead of
	newline-delimited. This option is deprecated in favor of
	`-Z` as the output can otherwise be ambiguous.


OUTPUT
------
If `-t` is specified, one of the `<type>`.

If `-s` is specified, the size of the `<object>` in bytes.

If `-e` is specified, no output, unless the `<object>` is malformed.

If `-p` is specified, the contents of `<object>` are pretty-printed.

If `<type>` is specified, the raw (though uncompressed) contents of the `<object>`
will be returned.

BATCH OUTPUT
------------

If `--batch` or `--batch-check` is given, `cat-file` will read objects
from stdin, one per line, and print information about them in the same
order as they have been read. By default, the whole line is
considered as an object, as if it were fed to linkgit:git-rev-parse[1].

When `--batch-command` is given, `cat-file` will read commands from