Repository navigation
Should gh release create push the local tag if it exists? #4357
Description
Activity
I tried to create a local tag for my repo and use
gh release create <that tag>and it works correctly... Maybe because I'm onHEAD?🤔 When I found this I was on version
2.0.0. I'll upgrade and test this out.No, looks like I'm still experiencing this issue. To clarify, what I'm doing is
git commit --allow-empty -m "new commit" # I do this to have a new commit to add a tag to git tag -a v1.2.3 # annotated commit gh release create v1.2.3 # select "no title" # select "Write using git tag message as template" # select "No" # select "Publish release"
At this point, a new release is created with tag
v1.2.3. However, this isn't the same tag, because it is missing the annotations. You can check this by cloning the repo that you created the release in to a new directory, and usinggit show v1.2.3to compare tag annotations between repos.
What's interesting is that the annotation is read bygh, or else I couldn't use the git tag message as a template for the release notes.Here's a repo that I made to test this out. You can fork it and use the script to try it out yourself.
Besides the tag message, it also looks like any GPG signature on the tag is also lost.Edit (2022/01/28): I deleted the linked repo, but this gist has the script for testing.
@spenserblack This behavior is mostly due to the restrictive nature of the release create API endpoint. It only allows for a tag name to be specified but no other properties, such as annotations, of the tag. The API will look in the repo for the tag or create a new one if one does not exist with the specified name, but the API won't have knowledge of a local non-pushed tag. Right now the workaround, as you mentioned, is to push the tag before doing
release create. I don't see whyghcouldn't handle this case though, but pushing a local tag if it exists locally and not on the remote. @mislav @vilmibm Is there any complexity here I am overlooking as to why we couldn't support this?Reacted by Spenser BlackI'm testing a patch that check locally the tag and push it before doing the rest, in order to avoid the manual workaround :)
Reacted by Sam Coe and Spenser Black@spenserblack I just opened a PR, but maybe you can check the fix on my fork
guerinoni:push-tag-locally-before-release:)Reacted by Spenser Black- added a commit that references this issue
on Jun 28, 2026
Describe the feature or problem you’d like to solve
When using
gh release createwith a tag that exists in the local repository but not inorigin, it creates a new tag instead of pushing the local tag. This seemed like confusing behavior to me.Proposed solution
If the tag name passed to
gh release createalready exists in the local repo, that tag should be pushed instead of a new tag with the same name being created for the release. This behavior might match the expected behavior.Additional context
Of course, there is a workaround for this already: push the tag before using
gh release create😆But, since other commands will push changes to the remote for you (like
gh pr create), I was a bit surprised thatgh release createdidn't push the local tag.