Hi Thanks for your quick reply. Just read the link and I agree it is not the right thing to do, especially when someone else has already picked up the tag. In such case, I fully agree, the developer should say "I messed up, sorry". Simultaneously, once such situation occurs, I think git should not claim all is up to date. It should not be the case on how tags are updated, that is work with "git fetch --tags", but not work with "git fetch --all --tags". I think by this developer's example, git should do the same: "I messed up, sorry, it's not actually up to date". Cheers Wojciech On 11 June 2014 11:55, Stefan Beller <stefanbeller@xxxxxxxxx> wrote: > On 11.06.2014 12:21, Wojciech Przybył wrote: >> Hi All >> >> When I was tagging, I think I might have discovered a git client bug. >> >> HOW TO REPRODUCE: >> - Clone a repo into 2 separate directories. Presume there is a tag >> "v0.1" already in there and it is set on say 10 commits ago. >> >> - In first directory change the tag to a different place and push it >> to the server: >> git tag -d v0.1 >> git tag v0.1 >> git push --tags origin master >> >> - In second directory try to update the tag... >> git pull --all --tags >> git fetch -all --tags >> THIS DOES NOT WORK, tag is still at old place, but it says "Already up-to-date". >> >> - I noticed when I use: >> git fetch --tags >> it works fine and updates the position of the tag, or if I remove tag >> from local git manually (rm .git/refs/tags/v0.1) and update again. >> >> Is it a bug or I am doing something wrong? I use git version 1.7.9.5. >> >> Cheers >> Wojciech > > Tags are intended to not change without the user knowing. > To gain more understanding on that, maybe read the man page of > git tag (see the discussion on retagging) > https://github.com/gitster/git/blob/master/Documentation/git-tag.txt#L166 -- 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