]>
Commit | Line | Data |
---|---|---|
215a7ad1 JH |
1 | git-tag(1) |
2 | ========== | |
2cf565c5 DG |
3 | |
4 | NAME | |
5 | ---- | |
453c1e85 | 6 | git-tag - Create, list, delete or verify a tag object signed with GPG |
2cf565c5 DG |
7 | |
8 | ||
2cf565c5 DG |
9 | SYNOPSIS |
10 | -------- | |
b867c7c2 | 11 | [verse] |
a2d07d80 | 12 | 'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] |
b85e6c5f NS |
13 | <tagname> [<commit> | <object>] |
14 | 'git tag' -d <tagname>... | |
ae7706b9 | 15 | 'git tag' [-n[<num>]] -l [--contains <commit>] [--points-at <object>] |
d96e3c15 | 16 | [--column[=<options>] | --no-column] [<pattern>...] |
ae7706b9 | 17 | [<pattern>...] |
b85e6c5f | 18 | 'git tag' -v <tagname>... |
2cf565c5 DG |
19 | |
20 | DESCRIPTION | |
21 | ----------- | |
18b07930 | 22 | |
831e61f8 | 23 | Add a tag reference in `refs/tags/`, unless `-d/-l/-v` is given |
cfb5e6b2 | 24 | to delete, list or verify tags. |
b7e438f9 | 25 | |
831e61f8 | 26 | Unless `-f` is given, the named tag must not yet exist. |
b7e438f9 | 27 | |
bc162e40 | 28 | If one of `-a`, `-s`, or `-u <key-id>` is passed, the command |
cfb5e6b2 | 29 | creates a 'tag' object, and requires a tag message. Unless |
62e09ce9 | 30 | `-m <msg>` or `-F <file>` is given, an editor is started for the user to type |
bc162e40 | 31 | in the tag message. |
b7e438f9 | 32 | |
995e8df4 DS |
33 | If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>` |
34 | are absent, `-a` is implied. | |
35 | ||
d5fa1f1a | 36 | Otherwise just a tag reference for the SHA-1 object name of the commit object is |
cfb5e6b2 | 37 | created (i.e. a lightweight tag). |
bc162e40 LT |
38 | |
39 | A GnuPG signed tag object will be created when `-s` or `-u | |
40 | <key-id>` is used. When `-u <key-id>` is not used, the | |
41 | committer identity for the current user is used to find the | |
0c5e70f0 JH |
42 | GnuPG key for signing. The configuration variable `gpg.program` |
43 | is used to specify custom GnuPG binary. | |
44 | ||
29d55538 DS |
45 | Tag objects (created with `-a`, `s`, or `-u`) are called "annotated" |
46 | tags; they contain a creation date, the tagger name and e-mail, a | |
47 | tagging message, and an optional GnuPG signature. Whereas a | |
48 | "lightweight" tag is simply a name for an object (usually a commit | |
49 | object). | |
50 | ||
51 | Annotated tags are meant for release while lightweight tags are meant | |
52 | for private or temporary object labels. For this reason, some git | |
53 | commands for naming objects (like `git describe`) will ignore | |
54 | lightweight tags by default. | |
55 | ||
2cf565c5 | 56 | |
d839091d NW |
57 | OPTIONS |
58 | ------- | |
59 | -a:: | |
c97eff5a | 60 | --annotate:: |
d839091d NW |
61 | Make an unsigned, annotated tag object |
62 | ||
63 | -s:: | |
c97eff5a | 64 | --sign:: |
0c5e70f0 | 65 | Make a GPG-signed tag, using the default e-mail address's key. |
d839091d NW |
66 | |
67 | -u <key-id>:: | |
c97eff5a | 68 | --local-user=<key-id>:: |
0c5e70f0 | 69 | Make a GPG-signed tag, using the given key. |
d839091d NW |
70 | |
71 | -f:: | |
f7aec129 | 72 | --force:: |
d839091d NW |
73 | Replace an existing tag with the given name (instead of failing) |
74 | ||
75 | -d:: | |
c97eff5a | 76 | --delete:: |
453c1e85 | 77 | Delete existing tags with the given names. |
d839091d | 78 | |
0bc72abd | 79 | -v:: |
c97eff5a | 80 | --verify:: |
62e09ce9 | 81 | Verify the gpg signature of the given tag names. |
0bc72abd | 82 | |
3f36cbba | 83 | -n<num>:: |
980ea5c5 MM |
84 | <num> specifies how many lines from the annotation, if any, |
85 | are printed when using -l. | |
86 | The default is not to print any annotation lines. | |
62e09ce9 | 87 | If no number is given to `-n`, only the first line is printed. |
abfd5fa8 | 88 | If the tag is not annotated, the commit message is displayed instead. |
980ea5c5 | 89 | |
b867c7c2 | 90 | -l <pattern>:: |
c97eff5a | 91 | --list <pattern>:: |
588d0e83 JK |
92 | List tags with names that match the given pattern (or all if no |
93 | pattern is given). Running "git tag" without arguments also | |
94 | lists all tags. The pattern is a shell wildcard (i.e., matched | |
95 | using fnmatch(3)). Multiple patterns may be given; if any of | |
96 | them matches, the tag is shown. | |
b867c7c2 | 97 | |
d96e3c15 NTND |
98 | --column[=<options>]:: |
99 | --no-column:: | |
100 | Display tag listing in columns. See configuration variable | |
101 | column.tag for option syntax.`--column` and `--no-column` | |
102 | without options are equivalent to 'always' and 'never' respectively. | |
103 | + | |
104 | This option is only applicable when listing tags without annotation lines. | |
105 | ||
32c35cfb JG |
106 | --contains <commit>:: |
107 | Only list tags which contain the specified commit. | |
108 | ||
ae7706b9 TG |
109 | --points-at <object>:: |
110 | Only list tags of the given object. | |
111 | ||
d839091d | 112 | -m <msg>:: |
c97eff5a | 113 | --message=<msg>:: |
bd46c9a9 | 114 | Use the given tag message (instead of prompting). |
d99bf51a | 115 | If multiple `-m` options are given, their values are |
bd46c9a9 | 116 | concatenated as separate paragraphs. |
995e8df4 DS |
117 | Implies `-a` if none of `-a`, `-s`, or `-u <key-id>` |
118 | is given. | |
d839091d | 119 | |
f79c73ce | 120 | -F <file>:: |
c97eff5a | 121 | --file=<file>:: |
f79c73ce JS |
122 | Take the tag message from the given file. Use '-' to |
123 | read the message from the standard input. | |
995e8df4 DS |
124 | Implies `-a` if none of `-a`, `-s`, or `-u <key-id>` |
125 | is given. | |
2cf565c5 | 126 | |
d3e05983 KS |
127 | --cleanup=<mode>:: |
128 | This option sets how the tag message is cleaned up. | |
129 | The '<mode>' can be one of 'verbatim', 'whitespace' and 'strip'. The | |
130 | 'strip' mode is default. The 'verbatim' mode does not change message at | |
131 | all, 'whitespace' removes just leading/trailing whitespace lines and | |
132 | 'strip' removes both whitespace and commentary. | |
133 | ||
b85e6c5f NS |
134 | <tagname>:: |
135 | The name of the tag to create, delete, or describe. | |
136 | The new tag name must pass all checks defined by | |
137 | linkgit:git-check-ref-format[1]. Some of these checks | |
138 | may restrict the characters allowed in a tag name. | |
139 | ||
dd686cd4 TR |
140 | <commit>:: |
141 | <object>:: | |
142 | The object that the new tag will refer to, usually a commit. | |
143 | Defaults to HEAD. | |
144 | ||
145 | ||
d67778ec AP |
146 | CONFIGURATION |
147 | ------------- | |
0b444cdb | 148 | By default, 'git tag' in sign-with-default mode (-s) will use your |
f430ed8b | 149 | committer identity (of the form "Your Name <\your@email.address>") to |
d67778ec AP |
150 | find a key. If you want to use a different default key, you can specify |
151 | it in the repository configuration as follows: | |
152 | ||
86b9e017 | 153 | ------------------------------------- |
d67778ec AP |
154 | [user] |
155 | signingkey = <gpg-key-id> | |
86b9e017 | 156 | ------------------------------------- |
d67778ec | 157 | |
4853534e JH |
158 | |
159 | DISCUSSION | |
160 | ---------- | |
161 | ||
162 | On Re-tagging | |
163 | ~~~~~~~~~~~~~ | |
164 | ||
165 | What should you do when you tag a wrong commit and you would | |
166 | want to re-tag? | |
167 | ||
168 | If you never pushed anything out, just re-tag it. Use "-f" to | |
169 | replace the old one. And you're done. | |
170 | ||
171 | But if you have pushed things out (or others could just read | |
172 | your repository directly), then others will have already seen | |
173 | the old tag. In that case you can do one of two things: | |
174 | ||
175 | . The sane thing. | |
176 | Just admit you screwed up, and use a different name. Others have | |
177 | already seen one tag-name, and if you keep the same name, you | |
178 | may be in the situation that two people both have "version X", | |
179 | but they actually have 'different' "X"'s. So just call it "X.1" | |
180 | and be done with it. | |
181 | ||
182 | . The insane thing. | |
183 | You really want to call the new version "X" too, 'even though' | |
0b444cdb | 184 | others have already seen the old one. So just use 'git tag -f' |
4853534e JH |
185 | again, as if you hadn't already published the old one. |
186 | ||
06ada152 | 187 | However, Git does *not* (and it should not) change tags behind |
46e56e81 | 188 | users back. So if somebody already got the old tag, doing a |
0b444cdb | 189 | 'git pull' on your tree shouldn't just make them overwrite the old |
4853534e JH |
190 | one. |
191 | ||
192 | If somebody got a release tag from you, you cannot just change | |
193 | the tag for them by updating your own one. This is a big | |
194 | security issue, in that people MUST be able to trust their | |
195 | tag-names. If you really want to do the insane thing, you need | |
196 | to just fess up to it, and tell people that you messed up. You | |
197 | can do that by making a very public announcement saying: | |
198 | ||
199 | ------------ | |
200 | Ok, I messed up, and I pushed out an earlier version tagged as X. I | |
201 | then fixed something, and retagged the *fixed* tree as X again. | |
202 | ||
203 | If you got the wrong tag, and want the new one, please delete | |
204 | the old one and fetch the new one by doing: | |
205 | ||
206 | git tag -d X | |
207 | git fetch origin tag X | |
208 | ||
209 | to get my updated tag. | |
210 | ||
211 | You can test which tag you have by doing | |
212 | ||
213 | git rev-parse X | |
214 | ||
215 | which should return 0123456789abcdef.. if you have the new version. | |
216 | ||
f1723ee6 | 217 | Sorry for the inconvenience. |
4853534e JH |
218 | ------------ |
219 | ||
220 | Does this seem a bit complicated? It *should* be. There is no | |
f1723ee6 MW |
221 | way that it would be correct to just "fix" it automatically. |
222 | People need to know that their tags might have been changed. | |
4853534e JH |
223 | |
224 | ||
225 | On Automatic following | |
226 | ~~~~~~~~~~~~~~~~~~~~~~ | |
227 | ||
228 | If you are following somebody else's tree, you are most likely | |
8b3f3f84 | 229 | using remote-tracking branches (`refs/heads/origin` in traditional |
4853534e JH |
230 | layout, or `refs/remotes/origin/master` in the separate-remote |
231 | layout). You usually want the tags from the other end. | |
232 | ||
233 | On the other hand, if you are fetching because you would want a | |
234 | one-shot merge from somebody else, you typically do not want to | |
235 | get tags from there. This happens more often for people near | |
236 | the toplevel but not limited to them. Mere mortals when pulling | |
237 | from each other do not necessarily want to automatically get | |
238 | private anchor point tags from the other person. | |
239 | ||
f1723ee6 MW |
240 | Often, "please pull" messages on the mailing list just provide |
241 | two pieces of information: a repo URL and a branch name; this | |
242 | is designed to be easily cut&pasted at the end of a 'git fetch' | |
243 | command line: | |
4853534e JH |
244 | |
245 | ------------ | |
246 | Linus, please pull from | |
247 | ||
248 | git://git..../proj.git master | |
249 | ||
250 | to get the following updates... | |
251 | ------------ | |
252 | ||
253 | becomes: | |
254 | ||
255 | ------------ | |
256 | $ git pull git://git..../proj.git master | |
257 | ------------ | |
258 | ||
f1723ee6 MW |
259 | In such a case, you do not want to automatically follow the other |
260 | person's tags. | |
4853534e | 261 | |
2de9b711 | 262 | One important aspect of Git is its distributed nature, which |
f1723ee6 | 263 | largely means there is no inherent "upstream" or |
4853534e JH |
264 | "downstream" in the system. On the face of it, the above |
265 | example might seem to indicate that the tag namespace is owned | |
f1723ee6 | 266 | by the upper echelon of people and that tags only flow downwards, but |
4853534e JH |
267 | that is not the case. It only shows that the usage pattern |
268 | determines who are interested in whose tags. | |
269 | ||
270 | A one-shot pull is a sign that a commit history is now crossing | |
271 | the boundary between one circle of people (e.g. "people who are | |
d99bf51a | 272 | primarily interested in the networking part of the kernel") who may |
4853534e JH |
273 | have their own set of tags (e.g. "this is the third release |
274 | candidate from the networking group to be proposed for general | |
275 | consumption with 2.6.21 release") to another circle of people | |
276 | (e.g. "people who integrate various subsystem improvements"). | |
277 | The latter are usually not interested in the detailed tags used | |
278 | internally in the former group (that is what "internal" means). | |
279 | That is why it is desirable not to follow tags automatically in | |
280 | this case. | |
281 | ||
282 | It may well be that among networking people, they may want to | |
283 | exchange the tags internal to their group, but in that workflow | |
f1723ee6 | 284 | they are most likely tracking each other's progress by |
8b3f3f84 | 285 | having remote-tracking branches. Again, the heuristic to automatically |
4853534e JH |
286 | follow such tags is a good thing. |
287 | ||
288 | ||
5040beff MO |
289 | On Backdating Tags |
290 | ~~~~~~~~~~~~~~~~~~ | |
291 | ||
292 | If you have imported some changes from another VCS and would like | |
293 | to add tags for major releases of your work, it is useful to be able | |
f1723ee6 | 294 | to specify the date to embed inside of the tag object; such data in |
5040beff MO |
295 | the tag object affects, for example, the ordering of tags in the |
296 | gitweb interface. | |
297 | ||
298 | To set the date used in future tag objects, set the environment | |
f1723ee6 MW |
299 | variable GIT_COMMITTER_DATE (see the later discussion of possible |
300 | values; the most common form is "YYYY-MM-DD HH:MM"). | |
5040beff | 301 | |
f1723ee6 | 302 | For example: |
5040beff MO |
303 | |
304 | ------------ | |
055b6615 | 305 | $ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1 |
5040beff MO |
306 | ------------ |
307 | ||
f1723ee6 | 308 | include::date-formats.txt[] |
5040beff | 309 | |
b85e6c5f NS |
310 | SEE ALSO |
311 | -------- | |
312 | linkgit:git-check-ref-format[1]. | |
313 | ||
2cf565c5 DG |
314 | GIT |
315 | --- | |
9e1f0a85 | 316 | Part of the linkgit:git[1] suite |