It has been a very conscious design decision that "git push" does not push tags without being told, as opposed to "git fetch" that can fetch tags that point at commits that are being transferred. The rationale is quite obvious, once you think about it. When fetching, you are interacting with a remote repository somebody has published, which means two important things: (1) the set of tags that exist there are all the publisher wanted people to see, and (2) not only you but other people will also see the same tags. In other words, tags in repositories you fetch from are designed to be public and shared. It will facilitate communication between developers if it is easy for everybody to fetch these same tags. When pushing, you are pushing from your working repository, which most of the time is not public, and tags in that repository is not designed to be public. You can use your own local tags to mark your progress, so it does not make sense to blindly push all tags in your repository to the repository you are pushing to publish your changes, whose tags are by definition public. Side note: the same logic applies to pushing branches. The branches in the remote you fetch from are public, the ones in your repository are mixture of branches for your private work and branches for public consumption. So the recommended workflow for publishers has always been: - work on private topic branches that do not have corresponding branches at the publishing repository to cook your work-in-progress; - integrate them when they are done to branches that do have corresponding branches at the publishing repository; - "git push" without any extra configuration will push "matching" branches, so that your private topic branches will stay private, and the integration branches used to communicate with everybody else will be pushed; - You can use a private tag to mark your point if you want to, and you can tag a release on a branch that is shared with public. - A new branch, or a new tag to be made public needs to be pushed explicitly. Requiring an explicit push, instead of blindly pushing everything, avoids contaminating the ref namespace of the public repository with your private topic branches and private tags by accident. But we could do better. Tags are designed to promote sharing of common reference points; the goal is to ensure that within the scope of a project, when somebody says v1.0 is buggy, everybody else knows exactly which version v1.0 refers to (this is the primary reason why we do not use separate-remote layout for tags). Which also means that there is a social convention among everybody in the project how public tags are named. Using a tag v2.4.3 to mark your private progress point, when the project uses tags that match "v*.*.*" to mark public releases, is not something any sane person would do. So, while we still should _never_ automatically push any tag that points at a commit that is being pushed out (i.e. inverse of "fetch" that auto follows tags), if the user or the project can give a clear enough hint to git which tags are for public consumption, we should at least be able to push tags that are for public consumption and do point at commits that are being pushed out. This is just me thinking out loud, but a typical end-user transcript may look something like this: Tell git that v*.* and v*.*.* are release tags (one-time set-up). $ git config --unset-all push.autotag $ git config --add push.autotag 'v*.*' $ git config --add push.autotag 'v*.*.*' Usual development process. $ git checkout master $ work work work Not very happy as the result is a mess, but it seems to work Ok. $ git tag wip Try it again with the wisdom gained from the previous attempt. $ rework rework rework How much improvement did we make? Hmm, looks good. $ git diff wip Use that for the release. $ git tag v1.2.0 Push it out, with the usual matching (or "upstream") semantics plus the new auto-follow tags feature. Note that "wip" tag will not be sent. $ git push -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html