GNOME Bugzilla – Bug 684247
git won't let me fix a bad tag
Last modified: 2013-05-28 18:15:01 UTC
I did "git push --tags origin master" and got back: * [new tag] 2.33.14 -> 2.33.14 ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'ssh://danw@git.gnome.org/git/glib-networking' hint: Updates were rejected because the tip of your current branch is behind etc etc etc (because a translator snuck in a commit while I wasn't paying attention). So I pulled, rebased, re-tagged, and tried to push again, but was told that it's not allowed to change a tag that's already been pushed. So now I'm in a situation where I can either (a) make the release from the existing tag which is not on any branch, or (b) have the tag point to the wrong place and use a different tag to identify the actual release. I did (b), but that's lame. So this is a request both for someone to fix the tags (delete the existing 2.33.14 and rename 2.33.14.1 to 2.33.14), and maybe to rethink the policy. (Do we have any information about how often the different commit-refusals get hit? If no one is hitting this accidentally, then I don't think there's any reason to block people from doing it on purpose.)
And now I've just discovered that I accidentally tagged glib-networking 2.34.2 as "2.40.2" (which was the libsoup version number at that time). So I guess I'll have to skip that version number in the future...
av temporarily disabled the checks for me so I could fix these two tags, so my particular issue is fixed. I still think you should disable this check permanently though :)
Note that av could have deleted the tag for you using 'git push --exec=force origin :tags/tagname' The reason we don't allow deleting or changing tags is that they are *not* overwritten locally if they change on the server, allowing some bad confusion - e.g. if someone else has a checkout of glib-networking and leave it checked out, then 2.40.2 for them will not updated to the new version.
That wouldn't have worked, the pre-receive hook would have blocked that, non-fast-forward pushes were enabled for glib-networking already (not sure why) but the problem was mainly related to the pre-receive hook blocking the push from updating the tags.
--exec=force disables some of the pre-receive checks, including (I think) this one. It's only available for sysadmins. non-fast-forward pushes are enabled for *all* repositories, and then we block them in pre-receive so that the pre-receive checks can allow some non-fast-forward pushes, such as ones with --exec=force and pushes by everybody to wip/ branches.
Thanks for the clarification Owen! Added this to my notes!