sha1-lookup: make selection of 'middle' less aggressive

diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 119117f0bdc689a4da1c1ba4b8ae9a41fd8f05fd..c22fb71176984f40e4b549d0d492f75af85e0e1b 100644 (file)
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -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).
 
@@ -34,13 +37,6 @@ A GnuPG signed tag object will be created when `-s` or `-u
 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::
@@ -72,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
 -------------
@@ -119,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.
@@ -221,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_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>,
@@ -232,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