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".


On 11 June 2014 11:55, Stefan Beller <stefanbel...@gmail.com> 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.
>> - 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
>> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to