| blob | 8c6e306aa24787400ca0e1da2782208db14365b4 |
4 <head>
9 /* Debug borders */
11 /*
12 border: 1px solid red;
13 */
14 }
16 body {
18 }
20 a {
23 }
26 }
28 em {
31 }
33 strong {
36 }
38 tt {
40 }
48 }
52 }
53 h2 {
55 }
56 h3 {
58 }
59 h3 + * {
61 }
66 }
68 hr {
70 }
72 p {
75 }
79 }
81 pre {
84 }
86 span#author {
91 }
92 span#email {
93 }
96 }
98 div#footer {
104 }
105 div#footer-text {
108 }
109 div#footer-badges {
112 }
114 div#preamble {
117 }
123 }
129 }
133 }
135 /* Block element titles. */
143 }
146 }
150 }
153 }
156 }
162 }
168 }
176 }
181 }
185 }
189 }
190 /* DEPRECATED: Pre version 8.2.7 verse style literal block. */
193 }
202 }
206 }
211 }
217 dl {
220 }
221 dt {
226 }
229 }
233 }
236 }
239 }
242 }
245 }
248 }
255 }
259 }
263 }
264 tfoot {
266 }
269 }
272 }
273 /* Because the table frame attribute is overriden by CSS in most browsers. */
276 }
280 }
284 }
290 }
293 }
296 }
302 }
305 }
309 }
313 }
317 }
321 }
326 }
330 }
340 }
345 }
347 div#toc {
349 }
351 div#toctitle {
358 }
363 }
367 }
371 }
375 }
376 /* Overrides for manpage documents */
377 h1 {
382 }
383 h2 {
385 }
388 }
392 }
394 /* Workarounds for IE6's broken and incomplete CSS2. */
400 }
407 }
413 }
418 }
422 }
426 }
431 }
433 /* IE6 sets dynamically generated links as visited. */
435 </style>
437 /*<![CDATA[*/
441 /////////////////////////////////////////////////////////////////////
442 // Table Of Contents generator
443 /////////////////////////////////////////////////////////////////////
445 /* Author: Mihai Bazon, September 2002
446 * http://students.infoiasi.ro/~mishoo
447 *
448 * Table Of Content generator
449 * Version: 0.4
450 *
451 * Feel free to use this script under the terms of the GNU General Public
452 * License, as long as you do not remove or alter this notice.
453 */
455 /* modified by Troy D. Hanson, September 2006. License: GPL */
456 /* modified by Stuart Rackham, 2006, 2009. License: GPL */
458 // toclevels = 1..4.
468 }
470 }
476 }
481 // Function that scans the DOM tree for header elements (the DOM2
482 // nodeIterator API would be a better technique but not supported by all
483 // browsers).
490 }
492 }
493 }
494 }
497 }
512 }
515 },
518 /////////////////////////////////////////////////////////////////////
519 // Footnotes generator
520 /////////////////////////////////////////////////////////////////////
522 /* Based on footnote generation code from:
523 * http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
524 */
534 n++;
535 // Use [\s\S] in place of . so multi-line matches work.
536 // Because JavaScript has no s (dotall) regex flag.
547 }
548 }
552 // Process footnoterefs.
561 }
562 }
563 }
564 }
566 }
567 /*]]>*/
568 </script>
569 </head>
570 <body>
572 <h1>
573 git-tag(1) Manual Page
574 </h1>
577 <p>git-tag -
578 Create, list, delete or verify a tag object signed with GPG
579 </p>
580 </div>
581 </div>
586 <div class="verseblock-content"><em>git tag</em> [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]
592 </div></div>
593 </div>
596 <div class="paragraph"><p>Add a tag reference in <tt>.git/refs/tags/</tt>, unless <tt>-d/-l/-v</tt> is given
597 to delete, list or verify tags.</p></div>
598 <div class="paragraph"><p>Unless <tt>-f</tt> is given, the tag to be created must not yet exist in the
600 <div class="paragraph"><p>If one of <tt>-a</tt>, <tt>-s</tt>, or <tt>-u <key-id></tt> is passed, the command
602 <tt>-m <msg></tt> or <tt>-F <file></tt> is given, an editor is started for the user to type
603 in the tag message.</p></div>
604 <div class="paragraph"><p>If <tt>-m <msg></tt> or <tt>-F <file></tt> is given and <tt>-a</tt>, <tt>-s</tt>, and <tt>-u <key-id></tt>
606 <div class="paragraph"><p>Otherwise just a tag reference for the SHA1 object name of the commit object is
607 created (i.e. a lightweight tag).</p></div>
610 committer identity for the current user is used to find the
611 GnuPG key for signing.</p></div>
612 </div>
617 -a
618 </dt>
620 --annotate
621 </dt>
622 <dd>
623 <p>
624 Make an unsigned, annotated tag object
625 </p>
626 </dd>
628 -s
629 </dt>
631 --sign
632 </dt>
633 <dd>
634 <p>
635 Make a GPG-signed tag, using the default e-mail address’s key
636 </p>
637 </dd>
640 </dt>
643 </dt>
644 <dd>
645 <p>
646 Make a GPG-signed tag, using the given key
647 </p>
648 </dd>
650 -f
651 </dt>
653 --force
654 </dt>
655 <dd>
656 <p>
657 Replace an existing tag with the given name (instead of failing)
658 </p>
659 </dd>
661 -d
662 </dt>
664 --delete
665 </dt>
666 <dd>
667 <p>
668 Delete existing tags with the given names.
669 </p>
670 </dd>
672 -v
673 </dt>
675 --verify
676 </dt>
677 <dd>
678 <p>
679 Verify the gpg signature of the given tag names.
680 </p>
681 </dd>
684 </dt>
685 <dd>
686 <p>
688 are printed when using -l.
689 The default is not to print any annotation lines.
691 If the tag is not annotated, the commit message is displayed instead.
692 </p>
693 </dd>
696 </dt>
699 </dt>
700 <dd>
701 <p>
702 List tags with names that match the given pattern (or all if no
703 pattern is given). Running "git tag" without arguments also
704 lists all tags. The pattern is a shell wildcard (i.e., matched
705 using fnmatch(3)). Multiple patterns may be given; if any of
706 them matches, the tag is shown.
707 </p>
708 </dd>
711 </dt>
712 <dd>
713 <p>
714 Only list tags which contain the specified commit.
715 </p>
716 </dd>
719 </dt>
722 </dt>
723 <dd>
724 <p>
725 Use the given tag message (instead of prompting).
727 concatenated as separate paragraphs.
729 is given.
730 </p>
731 </dd>
734 </dt>
737 </dt>
738 <dd>
739 <p>
741 read the message from the standard input.
743 is given.
744 </p>
745 </dd>
748 </dt>
749 <dd>
750 <p>
751 The name of the tag to create, delete, or describe.
752 The new tag name must pass all checks defined by
754 may restrict the characters allowed in a tag name.
755 </p>
756 </dd>
757 </dl></div>
758 </div>
761 <div class="paragraph"><p>By default, <em>git tag</em> in sign-with-default mode (-s) will use your
762 committer identity (of the form "Your Name <<a href="mailto:your@email.address">your@email.address</a>>") to
763 find a key. If you want to use a different default key, you can specify
764 it in the repository configuration as follows:</p></div>
767 <pre><tt>[user]
769 </div></div>
770 </div>
775 want to re-tag?</p></div>
779 your repository directly), then others will have already seen
780 the old tag. In that case you can do one of two things:</p></div>
782 <li>
783 <p>
784 The sane thing.
785 Just admit you screwed up, and use a different name. Others have
786 already seen one tag-name, and if you keep the same name, you
787 may be in the situation that two people both have "version X",
789 and be done with it.
790 </p>
791 </li>
792 <li>
793 <p>
794 The insane thing.
797 again, as if you hadn’t already published the old one.
798 </p>
799 </li>
800 </ol></div>
801 <div class="paragraph"><p>However, Git does <strong>not</strong> (and it should not) change tags behind
802 users back. So if somebody already got the old tag, doing a
804 one.</p></div>
806 the tag for them by updating your own one. This is a big
807 security issue, in that people MUST be able to trust their
808 tag-names. If you really want to do the insane thing, you need
809 to just fess up to it, and tell people that you messed up. You
810 can do that by making a very public announcement saying:</p></div>
813 <pre><tt>Ok, I messed up, and I pushed out an earlier version tagged as X. I
814 then fixed something, and retagged the *fixed* tree as X again.
816 If you got the wrong tag, and want the new one, please delete
817 the old one and fetch the new one by doing:
819 git tag -d X
820 git fetch origin tag X
822 to get my updated tag.
824 You can test which tag you have by doing
826 git rev-parse X
828 which should return 0123456789abcdef.. if you have the new version.
830 Sorry for the inconvenience.</tt></pre>
831 </div></div>
832 <div class="paragraph"><p>Does this seem a bit complicated? It <strong>should</strong> be. There is no
833 way that it would be correct to just "fix" it automatically.
834 People need to know that their tags might have been changed.</p></div>
839 layout). You usually want the tags from the other end.</p></div>
841 one-shot merge from somebody else, you typically do not want to
842 get tags from there. This happens more often for people near
843 the toplevel but not limited to them. Mere mortals when pulling
844 from each other do not necessarily want to automatically get
845 private anchor point tags from the other person.</p></div>
847 two pieces of information: a repo URL and a branch name; this
849 command line:</p></div>
852 <pre><tt>Linus, please pull from
854 git://git..../proj.git master
856 to get the following updates...</tt></pre>
857 </div></div>
862 </div></div>
866 largely means there is no inherent "upstream" or
867 "downstream" in the system. On the face of it, the above
868 example might seem to indicate that the tag namespace is owned
869 by the upper echelon of people and that tags only flow downwards, but
870 that is not the case. It only shows that the usage pattern
871 determines who are interested in whose tags.</p></div>
873 the boundary between one circle of people (e.g. "people who are
874 primarily interested in the networking part of the kernel") who may
875 have their own set of tags (e.g. "this is the third release
876 candidate from the networking group to be proposed for general
877 consumption with 2.6.21 release") to another circle of people
878 (e.g. "people who integrate various subsystem improvements").
879 The latter are usually not interested in the detailed tags used
880 internally in the former group (that is what "internal" means).
881 That is why it is desirable not to follow tags automatically in
882 this case.</p></div>
884 exchange the tags internal to their group, but in that workflow
885 they are most likely tracking each other’s progress by
886 having remote-tracking branches. Again, the heuristic to automatically
887 follow such tags is a good thing.</p></div>
890 to add tags for major releases of your work, it is useful to be able
891 to specify the date to embed inside of the tag object; such data in
892 the tag object affects, for example, the ordering of tags in the
893 gitweb interface.</p></div>
895 variable GIT_COMMITTER_DATE (see the later discussion of possible
901 </div></div>
902 </div>
906 support the following date formats:</p></div>
909 Git internal format
910 </dt>
911 <dd>
912 <p>
917 </p>
918 </dd>
920 RFC 2822
921 </dt>
922 <dd>
923 <p>
924 The standard email format as described by RFC 2822, for example
926 </p>
927 </dd>
929 ISO 8601
930 </dt>
931 <dd>
932 <p>
933 Time and date specified by the ISO 8601 standard, for example
936 </p>
938 <table><tr>
941 </td>
944 </tr></table>
945 </div>
946 </dd>
947 </dl></div>
948 </div>
951 <div class="paragraph"><p><a href="git-check-ref-format.html">git-check-ref-format(1)</a>.</p></div>
952 </div>
956 </div>
957 </div>
962 </div>
963 </div>
964 </body>
965 </html>