230

Since I created my repository it appears that the tags I have been creating are not pushed to the repository. When I do git tag on the local directory all the tags are present, but when I logon to the remote repository and do a git tag, only the first few show up.

What could the problem be?.

Jaime Hablutzel
  • 6,117
  • 5
  • 40
  • 57
vfclists
  • 19,193
  • 21
  • 73
  • 92
  • 3
    `git push --follow-tags` can now be useful, see [my answer below](http://stackoverflow.com/a/16164809/6309) – VonC Apr 23 '13 at 08:44
  • 2
    Possible duplicate of [How can I push a tag to a remote repository using Git?](http://stackoverflow.com/questions/5195859/how-can-i-push-a-tag-to-a-remote-repository-using-git). –  Apr 27 '14 at 19:52
  • 1
    Agree with duplicate: although this is older, the other question is better posed. – Ciro Santilli OurBigBook.com Oct 18 '14 at 09:13

5 Answers5

293

You could do this:

git push --tags
Matt Fenwick
  • 48,199
  • 22
  • 128
  • 192
eevar
  • 3,519
  • 1
  • 19
  • 9
  • 31
    I'm pretty sure that means that the HEAD refs won't get pushed, meaning that you ONLY push the tags. – Dan Rosenstark Oct 07 '12 at 21:01
  • 62
    "I recommend not using or training others to use `git push --tags` as it can be very very difficult to get rid of bad tags when your co-workers are trained to push all tags, as people continue to push the old bad tags they have locally every time they want to push a new tag. Because of this, I will only every advise someone to use `git push origin ` now." - copied from http://stackoverflow.com/a/5195913/4130619 – reducing activity Aug 10 '15 at 16:46
  • 1
    I think the other answer, https://stackoverflow.com/a/16164809/11635 should be accepted. Even if not, it should definitely be read - it provides pros and cons and ultimately a more practical and correct answer for today – Ruben Bartelink Dec 23 '18 at 15:04
161

In default git remote configuration you have to push tags explicitly (while they are fetched automatically together with commits they point to). You need to use

$ git push <remote> tag <tagname>

to push a single tag, or

$ git push <remote> --tags

to push all tags (or git push --tags to push to default remote, usually origin).

This is very much intended behavior, to make pushing tags explicit. Pushing tags should be usually conscious choice.

Summarizing what Junio C. Hamano wrote (linked in comments by @Andre Miras)

When fetching, you are interacting with a remote repository somebody has published, which means:

  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.

That's why git fetch automatically "follows" tags, i.e. it downloads tags when downloading revisions they point to - in other words downloads all relevant published 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.

That's why you need to push tag explicitly, to mark tag as public.

Alternatively you can configure the remote you push to to always push all tags, e.g. put something like that in your .git/config:

[remote "publish"] # or whatever it is named
    url = ...
    push = +refs/heads/*:refs/heads/*
    push = +refs/tags/*:refs/tags/*

This means force push all heads (all branches) and all tags (if you don't want force pushing of heads, remove '+' prefix from refspec).

Jakub Narębski
  • 309,089
  • 65
  • 217
  • 230
  • Doesn't this always do a 'force push' of all heads ? – Stefan Näwe Jun 07 '10 at 12:56
  • @Stefan: Yes it does. Updated. – Jakub Narębski Jun 07 '10 at 14:19
  • 21
    "This is very much intended behaviour, to make pushing tags explicit. Pushing tags should be usually conscious choice." I don't understand the rationale. Can you elaborate on why it would be bad for Git to push tags automatically? – Ryan Lundy Aug 02 '11 at 18:28
  • 13
    @Kyralessa, in this post http://git.661346.n2.nabble.com/rfd-auto-following-tags-upon-quot-git-push-quot-td6450398.html, Junio C Hamano (current maintainer of Git) explains why it's a bad thing to automatically push tags. – Andre Miras Sep 10 '13 at 08:37
  • @AndreMiras Thank you for this awesome link. It would be nice if we could integrate Junio's post into this answer. – Homer6 Sep 16 '13 at 21:05
  • I've been looking for this answer for years. I just always want to push all tags and refs and this told me how, thanks! – Seiyria Jul 10 '20 at 12:44
  • Well that link is gone now, I wonder what it said. – O'Rooney Dec 16 '21 at 21:36
  • It still makes no sense to me. I can't imagine why I would ever want a "private" tag... – O'Rooney Dec 16 '21 at 21:36
  • @O'Rooney : you might want to use a temporary and private tag to, for example, mark where a feature was introduced in project history (as to not have to remember object-ids), but this tag would be a temporary help for you for restructuring the code, not for wide publishing. – Jakub Narębski Dec 22 '21 at 04:02
96

Note that since git 1.8.3 (April 22d, 2013), you no longer have to do 2 commands to push branches, and then to push tags:

The new "--follow-tags" option tells "git push" to push relevant annotated tags when pushing branches out.

You can now try, when pushing new commits:

git push --follow-tags

That won't push all the local tags though, only the annotated ones referenced by commits which are pushed with the git push.

This has been introduced in commit c2aba15 by Junio C Hamano (gitster):

The new option "--follow-tags" tells "git push" to push annotated tags that are missing from the other side and that can be reached by the history that is otherwise pushed out.

For example, if you are using the "simple", "current", or "upstream" push, you would ordinarily push the history leading to the commit at your current HEAD and nothing else.
With this option, you would also push all annotated tags that can be reached from that commit to the other side.

The config push.followTags allows to include --follow-tags by default (Git 2.4.1+, Q2 2015).   See "Push git commits & tags simultaneously"

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 3
    This only pushes all *annotated* tags. Most people/projects are using *lightweight* tags. So in most cases `git push --follow-tags` does not push more than `git push` – Jarl Jun 20 '14 at 06:45
  • 3
    @Jarl yes, I have mentioned "annotated" in my answer. But I really only have used annotated tags, reserving lightweight tags for purely internal usage (ie never meant to be pushed anyway). – VonC Jun 20 '14 at 06:49
  • 1
    @VonC: Now there's also a config option that makes this the default, as you noted here: http://stackoverflow.com/a/3745250/946850 – krlmlr Sep 10 '15 at 14:28
20

What I usually do is :

[remote "publish"] # or whatever it is named
    url = ...
    push = :
    push = +refs/tags/*:refs/tags/*

Meaning it pushes every branch that's already there, plus tags. It does not force push, and it does not push branch that you didn't push manually.

mat
  • 12,943
  • 5
  • 39
  • 44
  • Can I also put that in the global git config of my user? If yes, how? Thanks! :) – gucki Feb 08 '13 at 09:34
  • It looks like you are forcing the tags, but not the branches. – Adrian Ratnapala Apr 29 '13 at 06:36
  • Well, yes, and no, I wrote that, it will push new tags, it won't force push them, and it won't push branches that you haven't already pushed yourself. – mat Apr 29 '13 at 09:31
  • I tried Jakub's suggestion, but it was pushing branches that I only wanted locally. This suggestion, mat, works perfect. It syncs tags but does not sync branches unless they are remote tracking branches (i.e. it won't push new branches to the remote, but will update them if they are already in the remote). NOTE: if you have a tag and a branch with the same name you get "matches more than one" error. Refer to [lostechies.com/jasonmeridth/2010/02/27/refspec-matches-more-than-one/](http://lostechies.com/jasonmeridth/2010/02/27/refspec-matches-more-than-one/). – josephdpurcell Jun 13 '13 at 17:58
6

And if you want to force fetch all the tags, you may set it in the config by:

git config remote.origin.tagopt --tags

From the docs:

Setting this value to --no-tags disables automatic tag following when fetching from remote . Setting it to --tags will fetch every tag from remote , even if they are not reachable from remote branch heads. Passing these flags directly to git-fetch(1) can override this setting. See options --tags and --no-tags of git-fetch(1).

Matt Fenwick
  • 48,199
  • 22
  • 128
  • 192
boryn
  • 726
  • 9
  • 10
  • 1
    The question was more 'push' oriented, does your answer also apply when pushing to a remote? – a1an Sep 23 '15 at 13:57