Merge branch 'maint-1.5.4' into maint
[gitweb.git] / Documentation / git-tag.txt
index 990ae4f948920477500b6a19a2350a61cbd7c3cd..9712392f7946366129056ed8a0b7b8fab83c0ed5 100644 (file)
@@ -11,7 +11,7 @@ SYNOPSIS
 [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
@@ -26,6 +26,9 @@ creates a 'tag' object, and requires the tag message.  Unless
 `-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).
 
@@ -54,7 +57,7 @@ OPTIONS
 -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.
@@ -65,11 +68,17 @@ OPTIONS
        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
 -------------
@@ -112,7 +121,7 @@ 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
+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.
@@ -214,6 +223,27 @@ having tracking branches.  Again, the heuristic to automatically
 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>,
@@ -225,4 +255,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
 
 GIT
 ---
-Part of the gitlink:git[7] suite
+Part of the linkgit:git[7] suite