While I was reading about renaming of git tags , many people pointed to read this :
What should you do when you tag a wrong commit and you would want to re-tag?
If you never pushed anything out, just re-tag it. Use "-f" to replace the old one. And you’re done.
But if you have pushed things out (or others could just read your repository directly), then others will have already seen the old tag. In that case you can do one of two things:
The sane thing. Just admit you screwed up, and use a different name. Others have already seen one tag-name, and if you keep the same name, you may be in the situation that two people both have "version X", but they actually have different "X"'s. So just call it "X.1" and be done with it.
The insane thing. You really want to call the new version "X" too, even though others have already seen the old one. So just use git tag -f again, as if you hadn’t already published the old one.
However, Git does not (and it should not) change tags behind users back. So if somebody already got the old tag, doing a git pull on your tree shouldn’t just make them overwrite the old one.
If somebody got a release tag from you, you cannot just change the tag for them by updating your own one. This is a big security issue, in that people MUST be able to trust their tag-names. If you really want to do the insane thing, you need to just fess up to it, and tell people that you messed up.
Well, on retagging I asked an earlier question if you are interested - Git retagging sane and insane advice - Part 1 , however , it is not required. I have just chained the question as context is same.
So, my question is
I have 2 local repo of one remote - repo 1 and repo 2.
Step 1 : Create annotated tag in repo1 by name say X.
Step 2 : Push to remote.
Step 3 : Repo 2 pulls the tag.
Step 4 : Repo 1 deletes the Tag X and creates another tag X but with different message this time.
Step 5 : push to remote.
Step 6 : In repo2 , git pull --tags , updates the tag X.
How is this possible ? As highlighted above , git should not be doing this - that is updating tag ?
2 Answers
Answers 1
So if somebody already got the old tag,
That is your step 3.
shouldn’t just make them overwrite the old one.
Well it does not as it still holds old tag isn't it?
If somebody got a release tag from you, you cannot just change the tag for them by updating your own one.
So old one is in effect - everything is fine. You cannot change tag after pushing it.
Answers 2
It can be possible if your repo2 somehow configured to prune tags from the remote. For example there can be fetch.pruneTags=true in ~/.gitconfig or in some other place. If you want to figure it out run git config -l | grep fetch and look what it will print.
Prune tags is not default setting, so it is not reccomended to relay on that. You can use it on your controlled repos, but do not expect from other developers to have enabled prune-tags.
Detailed information is in the documentation:
Since keeping up-to-date with both branches and tags on the remote is a common use-case the --prune-tags option can be supplied along with --prune to prune local tags that don’t exist on the remote, and force-update those tags that differ. Tag pruning can also be enabled with fetch.pruneTags or remote..pruneTags in the config. See git-config.
The --prune-tags option is equivalent to having refs/tags/:refs/tags/ declared in the refspecs of the remote. This can lead to some seemingly strange interactions:
0 comments:
Post a Comment