[verse]
'git-tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <name> [<head>]
'git-tag' -d <name>...
-'git-tag' -l [<pattern>]
-'git-tag' -v <name>
+'git-tag'
[-n [<num>]] -l [<pattern>]
+'git-tag' -v <name>...
DESCRIPTION
-----------
If one of `-a`, `-s`, or `-u <key-id>` is passed, the command
creates a 'tag' object, and requires the tag message. Unless
-`-m <msg>` is given, an editor is started for the user to type
+`-m <msg>` or `-F <file>` is given, an editor is started for the user to type
in the tag message.
Otherwise just the SHA1 object name of the commit object is
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 that match the given pattern (or all
-if no pattern is given).
-
OPTIONS
-------
-a::
Delete existing tags with the given names.
-v::
- Verify the gpg signature of given the tag
+ Verify the gpg signature of the given tag names.
+
+-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.
+ If no number is given to `-n`, only the first line is printed.
-l <pattern>::
- List tags that match the given pattern (or all if no pattern is given).
+ List tags with names that match the given pattern (or all if no pattern is given).
+ 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.
-F <file>::
Take the tag message from the given file. Use '-' to
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_AUTHOR_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_AUTHOR_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