You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Another suggestion for creating annotated tags. Current text:
It's also important to create an annotated tag, otherwise the push will be rejected. Only annotated tags are allowed to be pushed.
It isn't clear why we would want annotated tags in git, nor what the developer's tag message should include. The text we've historically used in SVN is something like "Tag [import of] 1.2.3.4." But I'm not sure there's any reason for this in git — it's pretty clear what the plain tag vendor/foo/1.2.3.4 → commit (with message "Import 1.2.3.4").
Suggested action: either clarify what message should be used, or drop the annotated tags requirement (the latter is more of a policy change; feel free to close this issue if we want to drive that through git WG instead). Clarifying text would be something like: git tag -a vendor/NetBSD/mtree/20201211 -m "Tag mtree 20201211" in the example workflow, or adding a sentence to the existing text:
It's also important to create an annotated tag, otherwise the push will be rejected. Only annotated tags are allowed to be pushed. For our mtree example, that might be "Tag NetBSD/mtree 20201211."
Thanks!
The text was updated successfully, but these errors were encountered:
Another suggestion for creating annotated tags. Current text:
It isn't clear why we would want annotated tags in git, nor what the developer's tag message should include. The text we've historically used in SVN is something like "Tag [import of] 1.2.3.4." But I'm not sure there's any reason for this in git — it's pretty clear what the plain tag
vendor/foo/1.2.3.4
→commit
(with message "Import 1.2.3.4").Suggested action: either clarify what message should be used, or drop the annotated tags requirement (the latter is more of a policy change; feel free to close this issue if we want to drive that through git WG instead). Clarifying text would be something like:
git tag -a vendor/NetBSD/mtree/20201211 -m "Tag mtree 20201211"
in the example workflow, or adding a sentence to the existing text:Thanks!
The text was updated successfully, but these errors were encountered: