]>
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] |
f6a8ef07 | 12 | 'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] [-e] |
066cef77 | 13 | [(--trailer <token>[(=|:)<value>])...] |
b85e6c5f NS |
14 | <tagname> [<commit> | <object>] |
15 | 'git tag' -d <tagname>... | |
80f4cd80 | 16 | 'git tag' [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>] |
783b8292 ÆAB |
17 | [--points-at <object>] [--column[=<options>] | --no-column] |
18 | [--create-reflog] [--sort=<key>] [--format=<format>] | |
21bf9339 | 19 | [--merged <commit>] [--no-merged <commit>] [<pattern>...] |
07d347cf | 20 | 'git tag' -v [--format=<format>] <tagname>... |
2cf565c5 DG |
21 | |
22 | DESCRIPTION | |
23 | ----------- | |
18b07930 | 24 | |
831e61f8 | 25 | Add a tag reference in `refs/tags/`, unless `-d/-l/-v` is given |
cfb5e6b2 | 26 | to delete, list or verify tags. |
b7e438f9 | 27 | |
831e61f8 | 28 | Unless `-f` is given, the named tag must not yet exist. |
b7e438f9 | 29 | |
f6a8ef07 | 30 | If one of `-a`, `-s`, or `-u <key-id>` is passed, the command |
cfb5e6b2 | 31 | creates a 'tag' object, and requires a tag message. Unless |
62e09ce9 | 32 | `-m <msg>` or `-F <file>` is given, an editor is started for the user to type |
bc162e40 | 33 | in the tag message. |
b7e438f9 | 34 | |
066cef77 JP |
35 | If `-m <msg>` or `-F <file>` or `--trailer <token>[=<value>]` is given |
36 | and `-a`, `-s`, and `-u <key-id>` are absent, `-a` is implied. | |
995e8df4 | 37 | |
590551ca RD |
38 | Otherwise, a tag reference that points directly at the given object |
39 | (i.e., a lightweight tag) is created. | |
bc162e40 LT |
40 | |
41 | A GnuPG signed tag object will be created when `-s` or `-u | |
f6a8ef07 | 42 | <key-id>` is used. When `-u <key-id>` is not used, the |
bc162e40 | 43 | committer identity for the current user is used to find the |
0c5e70f0 JH |
44 | GnuPG key for signing. The configuration variable `gpg.program` |
45 | is used to specify custom GnuPG binary. | |
46 | ||
eeff891a | 47 | Tag objects (created with `-a`, `-s`, or `-u`) are called "annotated" |
29d55538 DS |
48 | tags; they contain a creation date, the tagger name and e-mail, a |
49 | tagging message, and an optional GnuPG signature. Whereas a | |
50 | "lightweight" tag is simply a name for an object (usually a commit | |
51 | object). | |
52 | ||
53 | Annotated tags are meant for release while lightweight tags are meant | |
54 | for private or temporary object labels. For this reason, some git | |
55 | commands for naming objects (like `git describe`) will ignore | |
56 | lightweight tags by default. | |
57 | ||
2cf565c5 | 58 | |
d839091d NW |
59 | OPTIONS |
60 | ------- | |
61 | -a:: | |
c97eff5a | 62 | --annotate:: |
d839091d NW |
63 | Make an unsigned, annotated tag object |
64 | ||
65 | -s:: | |
c97eff5a | 66 | --sign:: |
0c5e70f0 | 67 | Make a GPG-signed tag, using the default e-mail address's key. |
1c6b565f | 68 | The default behavior of tag GPG-signing is controlled by `tag.gpgSign` |
031fd4b9 | 69 | configuration variable if it exists, or disabled otherwise. |
1c6b565f TM |
70 | See linkgit:git-config[1]. |
71 | ||
72 | --no-sign:: | |
73 | Override `tag.gpgSign` configuration variable that is | |
74 | set to force each and every tag to be signed. | |
d839091d | 75 | |
f6a8ef07 ÆAB |
76 | -u <key-id>:: |
77 | --local-user=<key-id>:: | |
0c5e70f0 | 78 | Make a GPG-signed tag, using the given key. |
d839091d NW |
79 | |
80 | -f:: | |
f7aec129 | 81 | --force:: |
d839091d NW |
82 | Replace an existing tag with the given name (instead of failing) |
83 | ||
84 | -d:: | |
c97eff5a | 85 | --delete:: |
453c1e85 | 86 | Delete existing tags with the given names. |
d839091d | 87 | |
0bc72abd | 88 | -v:: |
c97eff5a | 89 | --verify:: |
bc913167 | 90 | Verify the GPG signature of the given tag names. |
0bc72abd | 91 | |
3f36cbba | 92 | -n<num>:: |
980ea5c5 | 93 | <num> specifies how many lines from the annotation, if any, |
6a338149 ÆAB |
94 | are printed when using -l. Implies `--list`. |
95 | + | |
96 | The default is not to print any annotation lines. | |
97 | If no number is given to `-n`, only the first line is printed. | |
98 | If the tag is not annotated, the commit message is displayed instead. | |
980ea5c5 | 99 | |
c485b24c ÆAB |
100 | -l:: |
101 | --list:: | |
102 | List tags. With optional `<pattern>...`, e.g. `git tag --list | |
103 | 'v-*'`, list only the tags that match the pattern(s). | |
104 | + | |
105 | Running "git tag" without arguments also lists all tags. The pattern | |
106 | is a shell wildcard (i.e., matched using fnmatch(3)). Multiple | |
107 | patterns may be given; if any of them matches, the tag is shown. | |
6a338149 ÆAB |
108 | + |
109 | This option is implicitly supplied if any other list-like option such | |
110 | as `--contains` is provided. See the documentation for each of those | |
111 | options for details. | |
b867c7c2 | 112 | |
b7cc53e9 KN |
113 | --sort=<key>:: |
114 | Sort based on the key given. Prefix `-` to sort in | |
115 | descending order of the value. You may use the --sort=<key> option | |
116 | multiple times, in which case the last key becomes the primary | |
117 | key. Also supports "version:refname" or "v:refname" (tag | |
64f7a264 | 118 | names are treated as versions). The "version:refname" sort |
c026557a SG |
119 | order can also be affected by the "versionsort.suffix" |
120 | configuration variable. | |
b7cc53e9 | 121 | The keys supported are the same as those in `git for-each-ref`. |
ae9f6311 | 122 | Sort order defaults to the value configured for the `tag.sort` |
64f7a264 MH |
123 | variable if it exists, or lexicographic order otherwise. See |
124 | linkgit:git-config[1]. | |
9ef176b5 | 125 | |
dd61cc1c | 126 | --color[=<when>]:: |
0c88bf50 JK |
127 | Respect any colors specified in the `--format` option. The |
128 | `<when>` field must be one of `always`, `never`, or `auto` (if | |
129 | `<when>` is absent, behave as if `always` was given). | |
130 | ||
3bb16a8b NTND |
131 | -i:: |
132 | --ignore-case:: | |
133 | Sorting and filtering tags are case insensitive. | |
134 | ||
aabfdc95 ØW |
135 | --omit-empty:: |
136 | Do not print a newline after formatted refs where the format expands | |
137 | to the empty string. | |
138 | ||
d96e3c15 NTND |
139 | --column[=<options>]:: |
140 | --no-column:: | |
141 | Display tag listing in columns. See configuration variable | |
1b5b8cf0 | 142 | `column.tag` for option syntax. `--column` and `--no-column` |
d96e3c15 NTND |
143 | without options are equivalent to 'always' and 'never' respectively. |
144 | + | |
145 | This option is only applicable when listing tags without annotation lines. | |
146 | ||
81966ab2 NTND |
147 | --contains [<commit>]:: |
148 | Only list tags which contain the specified commit (HEAD if not | |
6a338149 | 149 | specified). Implies `--list`. |
32c35cfb | 150 | |
ac3f5a34 ÆAB |
151 | --no-contains [<commit>]:: |
152 | Only list tags which don't contain the specified commit (HEAD if | |
153 | not specified). Implies `--list`. | |
154 | ||
b0840609 | 155 | --merged [<commit>]:: |
8881d35c | 156 | Only list tags whose commits are reachable from the specified |
21bf9339 | 157 | commit (`HEAD` if not specified). |
b0840609 ÆAB |
158 | |
159 | --no-merged [<commit>]:: | |
8881d35c | 160 | Only list tags whose commits are not reachable from the specified |
21bf9339 | 161 | commit (`HEAD` if not specified). |
0488792d | 162 | |
ae7706b9 | 163 | --points-at <object>:: |
1e0c3b68 ÆAB |
164 | Only list tags of the given object (HEAD if not |
165 | specified). Implies `--list`. | |
ae7706b9 | 166 | |
d839091d | 167 | -m <msg>:: |
c97eff5a | 168 | --message=<msg>:: |
bd46c9a9 | 169 | Use the given tag message (instead of prompting). |
d99bf51a | 170 | If multiple `-m` options are given, their values are |
bd46c9a9 | 171 | concatenated as separate paragraphs. |
f6a8ef07 | 172 | Implies `-a` if none of `-a`, `-s`, or `-u <key-id>` |
995e8df4 | 173 | is given. |
d839091d | 174 | |
f79c73ce | 175 | -F <file>:: |
c97eff5a | 176 | --file=<file>:: |
f79c73ce JS |
177 | Take the tag message from the given file. Use '-' to |
178 | read the message from the standard input. | |
f6a8ef07 | 179 | Implies `-a` if none of `-a`, `-s`, or `-u <key-id>` |
995e8df4 | 180 | is given. |
2cf565c5 | 181 | |
066cef77 JP |
182 | --trailer <token>[(=|:)<value>]:: |
183 | Specify a (<token>, <value>) pair that should be applied as a | |
184 | trailer. (e.g. `git tag --trailer "Custom-Key: value"` | |
185 | will add a "Custom-Key" trailer to the tag message.) | |
186 | The `trailer.*` configuration variables | |
187 | (linkgit:git-interpret-trailers[1]) can be used to define if | |
188 | a duplicated trailer is omitted, where in the run of trailers | |
189 | each trailer would appear, and other details. | |
190 | The trailers can be extracted in `git tag --list`, using | |
191 | `--format="%(trailers)"` placeholder. | |
192 | ||
9eed6e40 NMC |
193 | -e:: |
194 | --edit:: | |
195 | The message taken from file with `-F` and command line with | |
196 | `-m` are usually used as the tag message unmodified. | |
197 | This option lets you further edit the message taken from these sources. | |
198 | ||
d3e05983 KS |
199 | --cleanup=<mode>:: |
200 | This option sets how the tag message is cleaned up. | |
201 | The '<mode>' can be one of 'verbatim', 'whitespace' and 'strip'. The | |
202 | 'strip' mode is default. The 'verbatim' mode does not change message at | |
203 | all, 'whitespace' removes just leading/trailing whitespace lines and | |
204 | 'strip' removes both whitespace and commentary. | |
205 | ||
144c76fa | 206 | --create-reflog:: |
341fb286 CW |
207 | Create a reflog for the tag. To globally enable reflogs for tags, see |
208 | `core.logAllRefUpdates` in linkgit:git-config[1]. | |
67c70bd9 CW |
209 | The negated form `--no-create-reflog` only overrides an earlier |
210 | `--create-reflog`, but currently does not negate the setting of | |
c3342b36 | 211 | `core.logAllRefUpdates`. |
144c76fa | 212 | |
a5e14ea1 AH |
213 | --format=<format>:: |
214 | A string that interpolates `%(fieldname)` from a tag ref being shown | |
215 | and the object it points at. The format is the same as | |
216 | that of linkgit:git-for-each-ref[1]. When unspecified, | |
217 | defaults to `%(refname:strip=2)`. | |
218 | ||
b85e6c5f NS |
219 | <tagname>:: |
220 | The name of the tag to create, delete, or describe. | |
221 | The new tag name must pass all checks defined by | |
222 | linkgit:git-check-ref-format[1]. Some of these checks | |
223 | may restrict the characters allowed in a tag name. | |
224 | ||
dd686cd4 TR |
225 | <commit>:: |
226 | <object>:: | |
227 | The object that the new tag will refer to, usually a commit. | |
228 | Defaults to HEAD. | |
229 | ||
d67778ec AP |
230 | CONFIGURATION |
231 | ------------- | |
0b444cdb | 232 | By default, 'git tag' in sign-with-default mode (-s) will use your |
d595bdc1 | 233 | committer identity (of the form `Your Name <your@email.address>`) to |
d67778ec AP |
234 | find a key. If you want to use a different default key, you can specify |
235 | it in the repository configuration as follows: | |
236 | ||
86b9e017 | 237 | ------------------------------------- |
d67778ec | 238 | [user] |
2162f9f6 | 239 | signingKey = <gpg-key-id> |
86b9e017 | 240 | ------------------------------------- |
d67778ec | 241 | |
de121ffe | 242 | `pager.tag` is only respected when listing tags, i.e., when `-l` is |
ff1e7248 | 243 | used or implied. The default is to use a pager. |
de121ffe | 244 | See linkgit:git-config[1]. |
4853534e JH |
245 | |
246 | DISCUSSION | |
247 | ---------- | |
248 | ||
249 | On Re-tagging | |
250 | ~~~~~~~~~~~~~ | |
251 | ||
252 | What should you do when you tag a wrong commit and you would | |
253 | want to re-tag? | |
254 | ||
255 | If you never pushed anything out, just re-tag it. Use "-f" to | |
256 | replace the old one. And you're done. | |
257 | ||
258 | But if you have pushed things out (or others could just read | |
259 | your repository directly), then others will have already seen | |
260 | the old tag. In that case you can do one of two things: | |
261 | ||
262 | . The sane thing. | |
ba170517 JNA |
263 | Just admit you screwed up, and use a different name. Others have |
264 | already seen one tag-name, and if you keep the same name, you | |
265 | may be in the situation that two people both have "version X", | |
266 | but they actually have 'different' "X"'s. So just call it "X.1" | |
267 | and be done with it. | |
4853534e JH |
268 | |
269 | . The insane thing. | |
ba170517 JNA |
270 | You really want to call the new version "X" too, 'even though' |
271 | others have already seen the old one. So just use 'git tag -f' | |
272 | again, as if you hadn't already published the old one. | |
4853534e | 273 | |
06ada152 | 274 | However, Git does *not* (and it should not) change tags behind |
46e56e81 | 275 | users back. So if somebody already got the old tag, doing a |
0b444cdb | 276 | 'git pull' on your tree shouldn't just make them overwrite the old |
4853534e JH |
277 | one. |
278 | ||
279 | If somebody got a release tag from you, you cannot just change | |
280 | the tag for them by updating your own one. This is a big | |
281 | security issue, in that people MUST be able to trust their | |
282 | tag-names. If you really want to do the insane thing, you need | |
283 | to just fess up to it, and tell people that you messed up. You | |
284 | can do that by making a very public announcement saying: | |
285 | ||
286 | ------------ | |
287 | Ok, I messed up, and I pushed out an earlier version tagged as X. I | |
288 | then fixed something, and retagged the *fixed* tree as X again. | |
289 | ||
290 | If you got the wrong tag, and want the new one, please delete | |
291 | the old one and fetch the new one by doing: | |
292 | ||
293 | git tag -d X | |
294 | git fetch origin tag X | |
295 | ||
296 | to get my updated tag. | |
297 | ||
298 | You can test which tag you have by doing | |
299 | ||
300 | git rev-parse X | |
301 | ||
302 | which should return 0123456789abcdef.. if you have the new version. | |
303 | ||
f1723ee6 | 304 | Sorry for the inconvenience. |
4853534e JH |
305 | ------------ |
306 | ||
307 | Does this seem a bit complicated? It *should* be. There is no | |
f1723ee6 MW |
308 | way that it would be correct to just "fix" it automatically. |
309 | People need to know that their tags might have been changed. | |
4853534e JH |
310 | |
311 | ||
312 | On Automatic following | |
313 | ~~~~~~~~~~~~~~~~~~~~~~ | |
314 | ||
315 | If you are following somebody else's tree, you are most likely | |
749a2279 YK |
316 | using remote-tracking branches (eg. `refs/remotes/origin/master`). |
317 | You usually want the tags from the other end. | |
4853534e JH |
318 | |
319 | On the other hand, if you are fetching because you would want a | |
320 | one-shot merge from somebody else, you typically do not want to | |
321 | get tags from there. This happens more often for people near | |
322 | the toplevel but not limited to them. Mere mortals when pulling | |
323 | from each other do not necessarily want to automatically get | |
324 | private anchor point tags from the other person. | |
325 | ||
f1723ee6 MW |
326 | Often, "please pull" messages on the mailing list just provide |
327 | two pieces of information: a repo URL and a branch name; this | |
328 | is designed to be easily cut&pasted at the end of a 'git fetch' | |
329 | command line: | |
4853534e JH |
330 | |
331 | ------------ | |
332 | Linus, please pull from | |
333 | ||
334 | git://git..../proj.git master | |
335 | ||
336 | to get the following updates... | |
337 | ------------ | |
338 | ||
339 | becomes: | |
340 | ||
341 | ------------ | |
342 | $ git pull git://git..../proj.git master | |
343 | ------------ | |
344 | ||
f1723ee6 MW |
345 | In such a case, you do not want to automatically follow the other |
346 | person's tags. | |
4853534e | 347 | |
2de9b711 | 348 | One important aspect of Git is its distributed nature, which |
f1723ee6 | 349 | largely means there is no inherent "upstream" or |
4853534e JH |
350 | "downstream" in the system. On the face of it, the above |
351 | example might seem to indicate that the tag namespace is owned | |
f1723ee6 | 352 | by the upper echelon of people and that tags only flow downwards, but |
4853534e JH |
353 | that is not the case. It only shows that the usage pattern |
354 | determines who are interested in whose tags. | |
355 | ||
356 | A one-shot pull is a sign that a commit history is now crossing | |
357 | the boundary between one circle of people (e.g. "people who are | |
d99bf51a | 358 | primarily interested in the networking part of the kernel") who may |
4853534e JH |
359 | have their own set of tags (e.g. "this is the third release |
360 | candidate from the networking group to be proposed for general | |
361 | consumption with 2.6.21 release") to another circle of people | |
362 | (e.g. "people who integrate various subsystem improvements"). | |
363 | The latter are usually not interested in the detailed tags used | |
364 | internally in the former group (that is what "internal" means). | |
365 | That is why it is desirable not to follow tags automatically in | |
366 | this case. | |
367 | ||
368 | It may well be that among networking people, they may want to | |
369 | exchange the tags internal to their group, but in that workflow | |
f1723ee6 | 370 | they are most likely tracking each other's progress by |
8b3f3f84 | 371 | having remote-tracking branches. Again, the heuristic to automatically |
4853534e JH |
372 | follow such tags is a good thing. |
373 | ||
374 | ||
5040beff MO |
375 | On Backdating Tags |
376 | ~~~~~~~~~~~~~~~~~~ | |
377 | ||
378 | If you have imported some changes from another VCS and would like | |
379 | to add tags for major releases of your work, it is useful to be able | |
f1723ee6 | 380 | to specify the date to embed inside of the tag object; such data in |
5040beff MO |
381 | the tag object affects, for example, the ordering of tags in the |
382 | gitweb interface. | |
383 | ||
384 | To set the date used in future tag objects, set the environment | |
f1723ee6 MW |
385 | variable GIT_COMMITTER_DATE (see the later discussion of possible |
386 | values; the most common form is "YYYY-MM-DD HH:MM"). | |
5040beff | 387 | |
f1723ee6 | 388 | For example: |
5040beff MO |
389 | |
390 | ------------ | |
055b6615 | 391 | $ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1 |
5040beff MO |
392 | ------------ |
393 | ||
f1723ee6 | 394 | include::date-formats.txt[] |
5040beff | 395 | |
719515fd KH |
396 | FILES |
397 | ----- | |
398 | ||
399 | `$GIT_DIR/TAG_EDITMSG`:: | |
400 | This file contains the message of an in-progress annotated | |
401 | tag. If `git tag` exits due to an error before creating an | |
402 | annotated tag then the tag message that has been provided by the | |
403 | user in an editor session will be available in this file, but | |
404 | may be overwritten by the next invocation of `git tag`. | |
405 | ||
415af72b AL |
406 | NOTES |
407 | ----- | |
408 | ||
b59cdffd | 409 | include::ref-reachability-filters.txt[] |
415af72b | 410 | |
b85e6c5f NS |
411 | SEE ALSO |
412 | -------- | |
413 | linkgit:git-check-ref-format[1]. | |
b150794d | 414 | linkgit:git-config[1]. |
b85e6c5f | 415 | |
2cf565c5 DG |
416 | GIT |
417 | --- | |
9e1f0a85 | 418 | Part of the linkgit:git[1] suite |