GIT-FOR-EACH-REF(1) | Git Manual | GIT-FOR-EACH-REF(1) |
NAME
git-for-each-ref - Output information on each ref
SYNOPSIS
git for-each-ref [--count=<count>] [--shell|--perl|--python|--tcl] [(--sort=<key>)...] [--format=<format>] [--include-root-refs] [ --stdin | <pattern>... ] [--points-at=<object>] [--merged[=<object>]] [--no-merged[=<object>]] [--contains[=<object>]] [--no-contains[=<object>]] [--exclude=<pattern> ...]
DESCRIPTION
Iterate over all refs that match <pattern> and show them according to the given <format>, after sorting them according to the given set of <key>. If <count> is given, stop after showing that many refs. The interpolated values in <format> can optionally be quoted as string literals in the specified host language allowing their direct evaluation in that language.
OPTIONS
<pattern>...
--stdin
--count=<count>
--sort=<key>
--format=<format>
When unspecified, <format> defaults to %(objectname) SPC %(objecttype) TAB %(refname).
--color[=<when>]
--shell, --perl, --python, --tcl
--points-at=<object>
--merged[=<object>]
--no-merged[=<object>]
--contains[=<object>]
--no-contains[=<object>]
--ignore-case
--omit-empty
--exclude=<pattern>
--include-root-refs
FIELD NAMES
Various values from structured fields in referenced objects can be used to interpolate into the resulting output, or as sort keys.
For all objects, the following names can be used:
refname
strip can be used as a synonym to lstrip.
objecttype
objectsize
objectname
deltabase
upstream
For any remote-tracking branch %(upstream), %(upstream:remotename) and %(upstream:remoteref) refer to the name of the remote and the name of the tracked remote ref, respectively. In other words, the remote-tracking branch can be updated explicitly and individually by using the refspec %(upstream:remoteref):%(upstream) to fetch from %(upstream:remotename).
Has no effect if the ref does not have tracking information associated with it. All the options apart from nobracket are mutually exclusive, but if used together the last option is selected.
push
HEAD
color
align
if
symref
signature
signature:grade
signature:signer
signature:key
signature:fingerprint
signature:primarykeyfingerprint
signature:trustlevel
worktreepath
ahead-behind:<committish>
is-base:<committish>
For example, consider the following figure of first-parent histories of several refs:
*--*--*--*--*--* refs/heads/A \ \ *--*--*--* refs/heads/B \ \ \ \ * * refs/heads/C \ \ *--* refs/heads/D
Here, if A, B, and C are the filtered references, and the format string is %(refname):%(is-base:D), then the output would be
refs/heads/A: refs/heads/B:(D) refs/heads/C:
This is because the first-parent history of D has its earliest intersection with the first-parent histories of the filtered refs at a common first-parent ancestor of B and C and ties are broken by the earliest ref in the sorted order.
Note that this token will not appear if the first-parent history of <committish> does not intersect the first-parent histories of the filtered refs.
describe[:options]
tags=<bool-value>
abbrev=<number>
match=<pattern>
exclude=<pattern>
In addition to the above, for commit and tag objects, the header field names (tree, parent, object, type, and tag) can be used to specify the value in the header field. Fields tree and parent can also be used with modifier :short and :short=<length> just like objectname.
For commit and tag objects, the special creatordate and creator fields will correspond to the appropriate date or name-email-date tuple from the committer or tagger fields depending on the object type. These are intended for working on a mix of annotated and lightweight tags.
For tag objects, a fieldname prefixed with an asterisk (*) expands to the fieldname value of the peeled object, rather than that of the tag object itself.
Fields that have name-email-date tuple as its value (author, committer, and tagger) can be suffixed with name, email, and date to extract the named component. For email fields (authoremail, committeremail and taggeremail), :trim can be appended to get the email without angle brackets, and :localpart to get the part before the @ symbol out of the trimmed email. In addition to these, the :mailmap option and the corresponding :mailmap,trim and :mailmap,localpart can be used (order does not matter) to get values of the name and email according to the .mailmap file or according to the file set in the mailmap.file or mailmap.blob configuration variable (see gitmailmap(5)).
The raw data in an object is raw.
raw:size
Note that --format=%(raw) can not be used with --python, --shell, --tcl, because such language may not support arbitrary binary data in their string variable type.
The message in a commit or a tag object is contents, from which contents:<part> can be used to extract various parts out of:
contents:size
contents:subject
contents:body
contents:signature
contents:lines=N
Additionally, the trailers as interpreted by git-interpret-trailers(1) are obtained as trailers[:options] (or by using the historical alias contents:trailers[:options]). For valid [:option] values see trailers section of git-log(1).
For sorting purposes, fields with numeric values sort in numeric order (objectsize, authordate, committerdate, creatordate, taggerdate). All other fields are used to sort in their byte-value order.
There is also an option to sort by versions, this can be done by using the fieldname version:refname or its alias v:refname.
In any case, a field name that refers to a field inapplicable to the object referred by the ref does not cause an error. It returns an empty string instead.
As a special case for the date-type fields, you may specify a format for the date by adding : followed by date format name (see the values the --date option to git-rev-list(1) takes). If this formatting is provided in a --sort key, references will be sorted according to the byte-value of the formatted string rather than the numeric value of the underlying timestamp.
Some atoms like %(align) and %(if) always require a matching %(end). We call them "opening atoms" and sometimes denote them as %($open).
When a scripting language specific quoting is in effect, everything between a top-level opening atom and its matching %(end) is evaluated according to the semantics of the opening atom and only its result from the top-level is quoted.
EXAMPLES
An example directly producing formatted text. Show the most recent 3 tagged commits:
#!/bin/sh git for-each-ref --count=3 --sort='-*authordate' \ --format='From: %(*authorname) %(*authoremail) Subject: %(*subject) Date: %(*authordate) Ref: %(*refname) %(*body) ' 'refs/tags'
A simple example showing the use of shell eval on the output, demonstrating the use of --shell. List the prefixes of all heads:
#!/bin/sh git for-each-ref --shell --format="ref=%(refname)" refs/heads | \ while read entry do eval "$entry" echo `dirname $ref` done
A bit more elaborate report on tags, demonstrating that the format may be an entire script:
#!/bin/sh fmt=' r=%(refname) t=%(*objecttype) T=${r#refs/tags/} o=%(*objectname) n=%(*authorname) e=%(*authoremail) s=%(*subject) d=%(*authordate) b=%(*body) kind=Tag if test "z$t" = z then # could be a lightweight tag t=%(objecttype) kind="Lightweight tag" o=%(objectname) n=%(authorname) e=%(authoremail) s=%(subject) d=%(authordate) b=%(body) fi echo "$kind $T points at a $t object $o" if test "z$t" = zcommit then echo "The commit was authored by $n $e at $d, and titled $s Its message reads as: " echo "$b" | sed -e "s/^/ /" echo fi ' eval=`git for-each-ref --shell --format="$fmt" \ --sort='*objecttype' \ --sort=-taggerdate \ refs/tags` eval "$eval"
An example to show the usage of %(if)...%(then)...%(else)...%(end). This prefixes the current branch with a star.
git for-each-ref --format="%(if)%(HEAD)%(then)* %(else) %(end)%(refname:short)" refs/heads/
An example to show the usage of %(if)...%(then)...%(end). This prints the authorname, if present.
git for-each-ref --format="%(refname)%(if)%(authorname)%(then) Authored by: %(authorname)%(end)"
CAVEATS
Note that the sizes of objects on disk are reported accurately, but care should be taken in drawing conclusions about which refs or objects are responsible for disk usage. The size of a packed non-delta object may be much larger than the size of objects which delta against it, but the choice of which object is the base and which is the delta is arbitrary and is subject to change during a repack.
Note also that multiple copies of an object may be present in the object database; in this case, it is undefined which copy’s size or delta base will be reported.
NOTES
When combining multiple --contains and --no-contains filters, only references that contain at least one of the --contains commits and contain none of the --no-contains commits are shown.
When combining multiple --merged and --no-merged filters, only references that are reachable from at least one of the --merged commits and from none of the --no-merged commits are shown.
SEE ALSO
GIT
Part of the git(1) suite
11/25/2024 | Git 2.47.1 |