[verse]
'git-tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <name> [<head>]
'git-tag' -d <name>...
-'git-tag' [-n
[<num>]] -l [<pattern>]
+'git-tag' [-n[<num>]] -l [<pattern>]
'git-tag' -v <name>...
DESCRIPTION
`-m <msg>` or `-F <file>` is given, an editor is started for the user to type
in the tag message.
+If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>`
+are absent, `-a` is implied.
+
Otherwise just the SHA1 object name of the commit object is
written (i.e. a lightweight tag).
committer identity for the current user is used to find the
GnuPG key for signing.
-`-d <tag>` deletes the tag.
-
-`-v <tag>` verifies the gpg signature of the tag.
-
-`-l <pattern>` lists tags with names that match the given pattern
-(or all if no pattern is given).
-
OPTIONS
-------
-a::
-v::
Verify the gpg signature of the given tag names.
--n <num>::
+-n<num>::
<num> specifies how many lines from the annotation, if any,
are printed when using -l.
The default is not to print any annotation lines.
Typing "git tag" without arguments, also lists all tags.
-m <msg>::
- Use the given tag message (instead of prompting)
+ Use the given tag message (instead of prompting).
+ If multiple `-m` options are given, there values are
+ concatenated as separate paragraphs.
+ Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
+ is given.
-F <file>::
Take the tag message from the given file. Use '-' to
read the message from the standard input.
+ Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
+ is given.
CONFIGURATION
-------------
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
+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.
follow such tags is a good thing.
+On Backdating Tags
+~~~~~~~~~~~~~~~~~~
+
+If you have imported some changes from another VCS and would like
+to add tags for major releases of your work, it is useful to be able
+to specify the date to embed inside of the tag object. The data in
+the tag object affects, for example, the ordering of tags in the
+gitweb interface.
+
+To set the date used in future tag objects, set the environment
+variable GIT_COMMITTER_DATE to one or more of the date and time. The
+date and time can be specified in a number of ways; the most common
+is "YYYY-MM-DD HH:MM".
+
+An example follows.
+
+------------
+$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1
+------------
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>,
GIT
---
-Part of the gitlink:git[7] suite
+Part of the linkgit:git[7] suite