`--create-reflog`, but currently does not negate the setting of
`core.logAllRefUpdates`.
+--format=<format>::
+ A string that interpolates `%(fieldname)` from a tag ref being shown
+ and the object it points at. The format is the same as
+ that of linkgit:git-for-each-ref[1]. When unspecified,
+ defaults to `%(refname:strip=2)`.
+
<tagname>::
The name of the tag to create, delete, or describe.
The new tag name must pass all checks defined by
The object that the new tag will refer to, usually a commit.
Defaults to HEAD.
-<format>::
- A string that interpolates `%(fieldname)` from a tag ref being shown
- and the object it points at. The format is the same as
- that of linkgit:git-for-each-ref[1]. When unspecified,
- defaults to `%(refname:strip=2)`.
-
CONFIGURATION
-------------
By default, 'git tag' in sign-with-default mode (-s) will use your
the old tag. In that case you can do one of two things:
. The sane thing.
-Just admit you screwed up, and use a different name. Others have
-already seen one tag-name, and if you keep the same name, you
-may be in the situation that two people both have "version X",
-but they actually have 'different' "X"'s. So just call it "X.1"
-and be done with it.
+ Just admit you screwed up, and use a different name. Others have
+ already seen one tag-name, and if you keep the same name, you
+ may be in the situation that two people both have "version X",
+ but they actually have 'different' "X"'s. So just call it "X.1"
+ and be done with it.
. The insane thing.
-You really want to call the new version "X" too, 'even though'
-others have already seen the old one. So just use 'git tag -f'
-again, as if you hadn't already published the old one.
+ You really want to call the new version "X" too, 'even though'
+ others have already seen the old one. So just use 'git tag -f'
+ again, as if you hadn't already published the old one.
However, Git does *not* (and it should not) change tags behind
users back. So if somebody already got the old tag, doing a