missing key) and "N" for no signature.

signature:signer::
	The signer of the GPG signature of a commit.

signature:key::
	The key of the GPG signature of a commit.

signature:fingerprint::
	The fingerprint of the GPG signature of a commit.

signature:primarykeyfingerprint::
	The primary key fingerprint of the GPG signature of a commit.

signature:trustlevel::
	The trust level of the GPG signature of a commit. Possible
	outputs are `ultimate`, `fully`, `marginal`, `never` and `undefined`.

worktreepath::
	The absolute path to the worktree in which the ref is checked
	out, if it is checked out in any linked worktree. Empty string
	otherwise.

ahead-behind:<committish>::
	Two integers, separated by a space, demonstrating the number of
	commits ahead and behind, respectively, when comparing the output
	ref to the `<committish>` specified in the format.

is-base:<committish>::
	In at most one row, `(<committish>)` will appear to indicate the ref
	that is most likely the ref used as a starting point for the branch
	that produced `<committish>`. This choice is made using a heuristic:
	choose the ref that minimizes the number of commits in the
	first-parent history of `<committish>` and not in the first-parent
	history of the ref.
+
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]::
	A human-readable name, like linkgit:git-describe[1];
	empty string for undescribable commits. The `describe` string may
	be followed by a colon and one or more comma-separated options.
+
--
tags=<bool-value>;;
	Instead of only considering annotated tags, consider
	lightweight tags as well; see the corresponding option in
	linkgit:git-describe[1] for details.
abbrev=<number>;;
	Use at least <number> hexadecimal digits; see the corresponding
	option in linkgit:git-describe[1] for details.
match=<pattern>;;
	Only consider tags matching the given `glob(7)` pattern,
	excluding the "refs/tags/" prefix; see the corresponding option
	in linkgit:git-describe[1] for details.
exclude=<pattern>;;
	Do not consider tags matching the given `glob(7)` pattern,
	excluding the "refs/tags/" prefix; see the corresponding option
	in linkgit:git-describe[1] for details.
--

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