git-cat-file(1) (original) (raw)

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 git-rev-parse(1).

When --batch-command is given, cat-file will read commands from stdin, one per line, and print information based on the command given. With--batch-command, the info command followed by an object will print information about the object the same way --batch-check would, and thecontents command followed by an object prints contents in the same way--batch would.

You can specify the information shown for each object by using a custom__. The is copied literally to stdout for each object, with placeholders of the form %(atom) expanded, followed by a newline. The available atoms are:

objectname

The full hex representation of the object name.

objecttype

The type of the object (the same as cat-file -t reports).

objectmode

If the specified object has mode information (such as a tree or index entry), the mode expressed as an octal integer. Otherwise, empty string.

objectsize

The size, in bytes, of the object (the same as cat-file -sreports).

objectsize:disk

The size, in bytes, that the object takes up on disk. See the note about on-disk sizes in the CAVEATS section below.

deltabase

If the object is stored as a delta on-disk, this expands to the full hex representation of the delta base object name. Otherwise, expands to the null OID (all zeroes). See CAVEATSbelow.

rest

If this atom is used in the output string, input lines are split at the first whitespace boundary. All characters before that whitespace are considered to be the object name; characters after that first run of whitespace (i.e., the "rest" of the line) are output in place of the %(rest) atom.

If no format is specified, the default format is %(objectname) %(objecttype) %(objectsize).

If --batch is specified, or if --batch-command is used with the contentscommand, the object information is followed by the object contents (consisting of %(objectsize) bytes), followed by a newline.

For example, --batch without a custom format would produce:

SP SP LF LF

Whereas --batch-check='%(objectname) %(objecttype)' would produce:

If a name is specified on stdin that cannot be resolved to an object in the repository, then cat-file will ignore any custom format and print:

If a name is specified on stdin that is filtered out via --filter=, then cat-file will ignore any custom format and print:

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:

If a name is specified that refers to a submodule entry in a tree and the target object does not exist in the repository, then cat-file will ignore any custom format and print (with the object ID of the submodule):

If --follow-symlinks is used, and a symlink in the repository points outside the repository, then cat-file will ignore any custom format and print:

symlink SP LF LF

The symlink will either be absolute (beginning with a /), or relative to the tree root. For instance, if dir/link points to .. / .. /foo, then__ will be .. /foo. is the size of the symlink in bytes.

If --follow-symlinks is used, the following error messages will be displayed:

is printed when the initial symlink requested does not exist.

dangling SP LF LF

is printed when the initial symlink exists, but something that it (transitive-of) points to does not.

loop SP LF LF

is printed for symlink loops (or any symlinks that require more than 40 link resolutions to resolve).

notdir SP LF LF

is printed when, during symlink resolution, a file is used as a directory name.

Alternatively, when -Z is passed, the line feeds in any of the above examples are replaced with NUL terminators. This ensures that output will be parsable if the output itself would contain a linefeed and is thus recommended for scripting purposes.