"Custom-Key: value"`
	will add a "Custom-Key" trailer to the tag message.)
	The `trailer.*` configuration variables
	(linkgit:git-interpret-trailers[1]) can be used to define if
	a duplicated trailer is omitted, where in the run of trailers
	each trailer would appear, and other details.
	The trailers can be extracted in `git tag --list`, using
	`--format="%(trailers)"` placeholder.

-e::
--edit::
	The message taken from file with `-F` and command line with
	`-m` are usually used as the tag message unmodified.
	This option lets you further edit the message taken from these sources.

--cleanup=<mode>::
	This option sets how the tag message is cleaned up.
	The  '<mode>' can be one of 'verbatim', 'whitespace' and 'strip'.  The
	'strip' mode is default. The 'verbatim' mode does not change message at
	all, 'whitespace' removes just leading/trailing whitespace lines and
	'strip' removes both whitespace and commentary.

--create-reflog::
	Create a reflog for the tag. To globally enable reflogs for tags, see
	`core.logAllRefUpdates` in linkgit:git-config[1].
	The negated form `--no-create-reflog` only overrides an earlier
	`--create-reflog`, but currently does not negate the setting of
	`core.logAllRefUpdates`.

--format=<format>::
	A string that interpolates `%(fieldname)` from a tag ref being shown
	and the object it points at.  The format is the same as
	that of linkgit:git-for-each-ref[1].  When unspecified,
	defaults to `%(refname:strip=2)`.

<tagname>::
	The name of the tag to create, delete, or describe.
	The new tag name must pass all checks defined by
	linkgit:git-check-ref-format[1].  Some of these checks
	may restrict the characters allowed in a tag name.

<commit>::
<object>::
	The object that the new tag will refer to, usually a commit.
	Defaults to HEAD.

CONFIGURATION
-------------
By default, 'git tag' in sign-with-default mode (-s) will use your
committer identity (of the form `Your Name <your@email.address>`) to
find a key.  If you want to use a different default key, you can specify
it in the repository configuration as follows:

-------------------------------------
[user]
    signingKey = <gpg-key-id>
-------------------------------------

`pager.tag` is only respected when listing tags, i.e., when `-l` is
used or implied. The default is to use a pager.
See linkgit:git-config[1].

DISCUSSION
----------

On Re-tagging
~~~~~~~~~~~~~

What should you do when you tag a wrong commit and you would
want to re-tag?

If you never pushed anything out, just re-tag it. Use "-f" to
replace the old one. And you're done.

But if you have pushed things out (or others could just read
your repository directly), then others will have already seen
the old tag. In that case you can do one of two things:

. The sane thing.
  Just admit you screwed up, and use a different name. Others have
  already seen one tag-name, and if you keep the same name, you
  may be in the situation that two people both have "version X",
  but they actually have 'different' "X"'s.  So just call it "X.1"
  and be done with it.

. The insane thing.
  You really want to call the new version "X" too, 'even though'
  others have already seen the old one. So just use 'git tag -f'
  again, as if you hadn't already published the old one.

However, Git does *not* (and it should not) change tags behind
users back. So if somebody already got the old tag, doing a
'git pull' on your tree shouldn't just make them overwrite the old
one.

If somebody got a release tag from you, you cannot just change
the tag for them by updating your own one. This is a big
security issue, in that people MUST be able to trust their
tag-names.  If you really want to do the insane thing, you need
to just fess up to it, and tell people that you messed up. You
can do that by making a very public announcement saying:

------------
Ok, I messed up, and I pushed out an earlier version tagged as X. I
then fixed something, and retagged the *fixed* tree as X again.

If you got the wrong tag, and want the