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