2005-05-10 23:32:30 +02:00
|
|
|
git-mktag(1)
|
|
|
|
============
|
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
2021-01-05 20:42:32 +01:00
|
|
|
git-mktag - Creates a tag object with extra validation
|
2005-05-10 23:32:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
2011-07-02 04:38:26 +02:00
|
|
|
[verse]
|
usage: do not insist that standard input must come from a file
The synopsys text and the usage string of subcommands that read list
of things from the standard input are often shown like this:
git gostak [--distim] < <list-of-doshes>
This is problematic in a number of ways:
* The way to use these commands is more often to feed them the
output from another command, not feed them from a file.
* Manual pages outside Git, commands that operate on the data read
from the standard input, e.g "sort", "grep", "sed", etc., are not
described with such a "< redirection-from-file" in their synopsys
text. Our doing so introduces inconsistency.
* We do not insist on where the output should go, by saying
git gostak [--distim] < <list-of-doshes> > <output>
* As it is our convention to enclose placeholders inside <braket>,
the redirection operator followed by a placeholder filename
becomes very hard to read, both in the documentation and in the
help text.
Let's clean them all up, after making sure that the documentation
clearly describes the modes that take information from the standard
input and what kind of things are expected on the input.
[jc: stole example for fmt-merge-msg from Jonathan]
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16 20:27:42 +02:00
|
|
|
'git mktag'
|
2005-05-10 23:32:30 +02:00
|
|
|
|
2021-01-06 12:47:27 +01:00
|
|
|
OPTIONS
|
|
|
|
-------
|
|
|
|
|
|
|
|
--strict::
|
|
|
|
By default mktag turns on the equivalent of
|
|
|
|
linkgit:git-fsck[1] `--strict` mode. Use `--no-strict` to
|
|
|
|
disable it.
|
|
|
|
|
2005-05-10 23:32:30 +02:00
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
2005-05-10 23:32:38 +02:00
|
|
|
|
2021-01-05 20:42:32 +01:00
|
|
|
Reads a tag contents on standard input and creates a tag object. The
|
|
|
|
output is the new tag's <object> identifier.
|
|
|
|
|
|
|
|
This command is mostly equivalent to linkgit:git-hash-object[1]
|
|
|
|
invoked with `-t tag -w --stdin`. I.e. both of these will create and
|
|
|
|
write a tag found in `my-tag`:
|
|
|
|
|
|
|
|
git mktag <my-tag
|
|
|
|
git hash-object -t tag -w --stdin <my-tag
|
|
|
|
|
|
|
|
The difference is that mktag will die before writing the tag if the
|
mktag: use fsck instead of custom verify_tag()
Change the validation logic in "mktag" to use fsck's fsck_tag()
instead of its own custom parser. Curiously the logic for both dates
back to the same commit[1]. Let's unify them so we're not maintaining
two sets functions to verify that a tag is OK.
The behavior of fsck_tag() and the old "mktag" code being removed here
is different in few aspects.
I think it makes sense to remove some of those checks, namely:
A. fsck only cares that the timezone matches [-+][0-9]{4}. The mktag
code disallowed values larger than 1400.
Yes there's currently no timezone with a greater offset[2], but
since we allow any number of non-offical timezones (e.g. +1234)
passing this through seems fine. Git also won't break in the
future if e.g. French Polynesia decides it needs to outdo the Line
Islands when it comes to timezone extravagance.
B. fsck allows missing author names such as "tagger <email>", mktag
wouldn't, but would allow e.g. "tagger [2 spaces] <email>" (but
not "tagger [1 space] <email>"). Now we allow all of these.
C. Like B, but "mktag" disallowed spaces in the <email> part, fsck
allows it.
In some ways fsck_tag() is stricter than "mktag" was, namely:
D. fsck disallows zero-padded dates, but mktag didn't care. So
e.g. the timestamp "0000000000 +0000" produces an error now. A
test in "t1006-cat-file.sh" relied on this, it's been changed to
use "hash-object" (without fsck) instead.
There was one check I deemed worth keeping by porting it over to
fsck_tag():
E. "mktag" did not allow any custom headers, and by extension (as an
empty commit is allowed) also forbade an extra stray trailing
newline after the headers it knew about.
Add a new check in the "ignore" category to fsck and use it. This
somewhat abuses the facility added in efaba7cc77f (fsck:
optionally ignore specific fsck issues completely, 2015-06-22).
This is somewhat of hack, but probably the least invasive change
we can make here. The fsck command will shuffle these categories
around, e.g. under --strict the "info" becomes a "warn" and "warn"
becomes "error". Existing users of fsck's (and others,
e.g. index-pack) --strict option rely on this.
So we need to put something into a category that'll be ignored by
all existing users of the API. Pretending that
fsck.extraHeaderEntry=error ("ignore" by default) was set serves
to do this for us.
1. ec4465adb38 (Add "tag" objects that can be used to sign other
objects., 2005-04-25)
2. https://en.wikipedia.org/wiki/List_of_UTC_time_offsets
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-05 20:42:46 +01:00
|
|
|
tag doesn't pass a linkgit:git-fsck[1] check.
|
|
|
|
|
|
|
|
The "fsck" check done mktag is stricter than what linkgit:git-fsck[1]
|
|
|
|
would run by default in that all `fsck.<msg-id>` messages are promoted
|
|
|
|
from warnings to errors (so e.g. a missing "tagger" line is an error).
|
|
|
|
|
|
|
|
Extra headers in the object are also an error under mktag, but ignored
|
2021-01-05 20:42:48 +01:00
|
|
|
by linkgit:git-fsck[1]. This extra check can be turned off by setting
|
|
|
|
the appropriate `fsck.<msg-id>` varible:
|
|
|
|
|
|
|
|
git -c fsck.extraHeaderEntry=ignore mktag <my-tag-with-headers
|
2005-05-10 23:32:38 +02:00
|
|
|
|
|
|
|
Tag Format
|
|
|
|
----------
|
usage: do not insist that standard input must come from a file
The synopsys text and the usage string of subcommands that read list
of things from the standard input are often shown like this:
git gostak [--distim] < <list-of-doshes>
This is problematic in a number of ways:
* The way to use these commands is more often to feed them the
output from another command, not feed them from a file.
* Manual pages outside Git, commands that operate on the data read
from the standard input, e.g "sort", "grep", "sed", etc., are not
described with such a "< redirection-from-file" in their synopsys
text. Our doing so introduces inconsistency.
* We do not insist on where the output should go, by saying
git gostak [--distim] < <list-of-doshes> > <output>
* As it is our convention to enclose placeholders inside <braket>,
the redirection operator followed by a placeholder filename
becomes very hard to read, both in the documentation and in the
help text.
Let's clean them all up, after making sure that the documentation
clearly describes the modes that take information from the standard
input and what kind of things are expected on the input.
[jc: stole example for fmt-merge-msg from Jonathan]
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16 20:27:42 +02:00
|
|
|
A tag signature file, to be fed to this command's standard input,
|
|
|
|
has a very simple fixed format: four lines of
|
2005-05-10 23:32:38 +02:00
|
|
|
|
2020-12-23 02:35:46 +01:00
|
|
|
object <hash>
|
2005-05-10 23:32:38 +02:00
|
|
|
type <typename>
|
|
|
|
tag <tagname>
|
2007-06-11 01:00:36 +02:00
|
|
|
tagger <tagger>
|
2005-05-10 23:32:38 +02:00
|
|
|
|
2007-06-11 01:00:36 +02:00
|
|
|
followed by some 'optional' free-form message (some tags created
|
2020-12-23 02:35:47 +01:00
|
|
|
by older Git may not have `tagger` line). The message, when it
|
2007-06-11 01:00:36 +02:00
|
|
|
exists, is separated by a blank line from the header. The
|
2013-01-21 20:17:53 +01:00
|
|
|
message part may contain a signature that Git itself doesn't
|
2007-06-11 01:00:36 +02:00
|
|
|
care about, but that can be verified with gpg.
|
2005-05-10 23:32:30 +02:00
|
|
|
|
|
|
|
GIT
|
|
|
|
---
|
2008-06-06 09:07:32 +02:00
|
|
|
Part of the linkgit:git[1] suite
|