git/Documentation/git-for-each-ref.txt

278 строки
8.2 KiB
Plaintext
Исходник Обычный вид История

git-for-each-ref(1)
===================
NAME
----
git-for-each-ref - Output information on each ref
SYNOPSIS
--------
[verse]
'git for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl]
[(--sort=<key>)...] [--format=<format>] [<pattern>...]
[--points-at <object>] [(--merged | --no-merged) [<object>]]
[--contains [<object>]]
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
-------
<count>::
By default the command shows all refs that match
`<pattern>`. This option makes it stop after showing
that many refs.
<key>::
A field name to sort on. Prefix `-` to sort in
descending order of the value. When unspecified,
`refname` is used. You may use the --sort=<key> option
multiple times, in which case the last key becomes the primary
key.
<format>::
A string that interpolates `%(fieldname)` from the
object pointed at by a ref being shown. If `fieldname`
is prefixed with an asterisk (`*`) and the ref points
at a tag object, the value for the field in the object
tag refers is used. When unspecified, defaults to
`%(objectname) SPC %(objecttype) TAB %(refname)`.
It also interpolates `%%` to `%`, and `%xx` where `xx`
are hex digits interpolates to character with hex code
`xx`; for example `%00` interpolates to `\0` (NUL),
`%09` to `\t` (TAB) and `%0a` to `\n` (LF).
<pattern>...::
If one or more patterns are given, only refs are shown that
match against at least one pattern, either using fnmatch(3) or
literally, in the latter case matching completely or from the
beginning up to a slash.
--shell::
--perl::
--python::
--tcl::
If given, strings that substitute `%(fieldname)`
placeholders are quoted as string literals suitable for
the specified host language. This is meant to produce
a scriptlet that can directly be `eval`ed.
--points-at <object>::
Only list refs which points at the given object.
--merged [<object>]::
Only list refs whose tips are reachable from the
specified commit (HEAD if not specified).
--no-merged [<object>]::
Only list refs whose tips are not reachable from the
specified commit (HEAD if not specified).
--contains [<object>]::
Only list refs which contain the specified commit (HEAD if not
specified).
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::
The name of the ref (the part after $GIT_DIR/).
for-each-ref: `:short` format for `refname` Tries to shorten the refname to a non-ambiguous name. Szeder Gábor noticed that the git bash completion takes a tremendous amount of time to strip leading components from heads and tags refs (i.e. refs/heads, refs/tags, ...). He proposed a new atom called 'refbasename' which removes at most two leading components from the ref name. I myself, proposed a more dynamic solution, which strips off common leading components with the matched pattern. But the current bash solution and both proposals suffer from one mayor problem: ambiguous refs. A ref is ambiguous, if it resolves to more than one full refs. I.e. given the refs refs/heads/xyzzy and refs/tags/xyzzy. The (short) ref xyzzy can point to both refs. ( Note: Its irrelevant whether the referenced objects are the same or not. ) This proposal solves this by checking for ambiguity of the shorten ref name. The shortening is done with the same rules for resolving refs but in the reverse order. The short name is checked if it resolves to a different ref. To continue the above example, the output would be like this: heads/xyzzy xyzzy So, if you want just tags, xyzzy is not ambiguous, because it will resolve to a tag. If you need the heads you get a also a non-ambiguous short form of the ref. To integrate this new format into the bash completion to get only non-ambiguous refs is beyond the scope of this patch. Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-06 01:16:23 +04:00
For a non-ambiguous short name of the ref append `:short`.
The option core.warnAmbiguousRefs is used to select the strict
tag: do not show ambiguous tag names as "tags/foo" Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11), git-tag has started showing tags with ambiguous names (i.e., when both "heads/foo" and "tags/foo" exists) as "tags/foo" instead of just "foo". This is both: - pointless; the output of "git tag" includes only refs/tags, so we know that "foo" means the one in "refs/tags". and - ambiguous; in the original output, we know that the line "foo" means that "refs/tags/foo" exists. In the new output, it is unclear whether we mean "refs/tags/foo" or "refs/tags/tags/foo". The reason this happens is that commit b7cc53e9 switched git-tag to use ref-filter's "%(refname:short)" output formatting, which was adapted from for-each-ref. This more general code does not know that we care only about tags, and uses shorten_unambiguous_ref to get the short-name. We need to tell it that we care only about "refs/tags/", and it should shorten with respect to that value. In theory, the ref-filter code could figure this out by us passing FILTER_REFS_TAGS. But there are two complications there: 1. The handling of refname:short is deep in formatting code that does not even have our ref_filter struct, let alone the arguments to the filter_ref struct. 2. In git v2.7.0, we expose the formatting language to the user. If we follow this path, it will mean that "%(refname:short)" behaves differently for "tag" versus "for-each-ref" (including "for-each-ref refs/tags/"), which can lead to confusion. Instead, let's add a new modifier to the formatting language, "strip", to remove a specific set of prefix components. This fixes "git tag", and lets users invoke the same behavior from their own custom formats (for "tag" or "for-each-ref") while leaving ":short" with its same consistent meaning in all places. We introduce a test in t7004 for "git tag", which fails without this patch. We also add a similar test in t3203 for "git branch", which does not actually fail. But since it is likely that "branch" will eventually use the same formatting code, the test helps defend against future regressions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26 06:00:05 +03:00
abbreviation mode. If `strip=<N>` is appended, strips `<N>`
slash-separated path components from the front of the refname
(e.g., `%(refname:strip=2)` turns `refs/tags/foo` into `foo`.
`<N>` must be a positive integer. If a displayed ref has fewer
components than `<N>`, the command aborts with an error.
objecttype::
The type of the object (`blob`, `tree`, `commit`, `tag`).
objectsize::
The size of the object (the same as 'git cat-file -s' reports).
objectname::
The object name (aka SHA-1).
For a non-ambiguous abbreviation of the object name append `:short`.
upstream::
The name of a local ref which can be considered ``upstream''
from the displayed ref. Respects `:short` in the same way as
`refname` above. Additionally respects `:track` to show
"[ahead N, behind M]" and `:trackshort` to show the terse
version: ">" (ahead), "<" (behind), "<>" (ahead and behind),
or "=" (in sync). Has no effect if the ref does not have
tracking information associated with it.
push::
The name of a local ref which represents the `@{push}` location
for the displayed ref. Respects `:short`, `:track`, and
`:trackshort` options as `upstream` does. Produces an empty
string if no `@{push}` ref is configured.
HEAD::
'*' if HEAD matches current ref (the checked out branch), ' '
otherwise.
color::
Change output color. Followed by `:<colorname>`, where names
are described in `color.branch.*`.
2015-09-11 18:03:07 +03:00
align::
Left-, middle-, or right-align the content between
%(align:...) and %(end). The "align:" is followed by
`width=<width>` and `position=<position>` in any order
separated by a comma, where the `<position>` is either left,
right or middle, default being left and `<width>` is the total
length of the content with alignment. For brevity, the
"width=" and/or "position=" prefixes may be omitted, and bare
<width> and <position> used instead. For instance,
`%(align:<width>,<position>)`. If the contents length is more
than the width then no alignment is performed. If used with
`--quote` everything in between %(align:...) and %(end) is
quoted, but if nested then only the topmost level performs
quoting.
2015-09-11 18:03:07 +03:00
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.
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.
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.
The complete message in a commit and tag object is `contents`.
Its first line is `contents:subject`, where subject is the concatenation
of all lines of the commit message up to the first blank line. The next
line is 'contents:body', where body is all of the lines after the first
blank line. The optional GPG signature is `contents:signature`. The
first `N` lines of the message is obtained using `contents:lines=N`.
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 linkgit:git-rev-list[1] takes).
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"
------------
SEE ALSO
--------
linkgit:git-show-ref[1]
GIT
---
Part of the linkgit:git[1] suite