If you force-push, you should let the other users know you are doing this, so that they can correct for it. ![]() (note: you don't need -tags if you're explicitly pushing just one tag ref-spec).ġOf course, the reason for this built-in hook is to help enforce the behavior that other users of that same remote-repo expect: that branches are not rewound, and tags do not move. If you want to be sure not to update anything other than the tag, just tell git push to push only that one refspec: git push -force origin refs/tags/dev:refs/tags/dev On the remote, dev will now be a newly created tag, so the remote will probably allow the push (again this depends on any extra hooks added). ![]() If it allows the deletion, then the tag will be gone, and a second git push -tags, when you have a local dev tag pointing to some commit or annotated tag repo object, send your new dev tag. The remote may or may not allow tag deletion (depending on any extra hooks added). The presence or absence of the tag dev in your local repository is irrelevant this kind of push, with : remoteref as a refspec, is a pure-delete push. Assuming the name of the remote is origin, and the tag you want it to delete is dev: git push origin :refs/tags/dev The latter is possible via git push 2 even though deleting the tag locally and pushing has no effect. If you delete the tag locally, then create it pointing to a new place, then push, your push transfers the tag, and the remote sees this as a tag-change and rejects the change, unless it's a force-push. The remote assumes no change should be made. If you delete the tag locally, then push, your push simply does not transfer the tag. For tags you don't have that they do, it also does nothing!) (For tags that are the same, it does nothing at all. The remote compares the values and if there are additions and/or changes, runs the hooks on those. It only says "here's my complete list of tags, along with their SHA-1 values". (Incidentally, this same built-in hook also rejects branch updates that are not fast-forwards.) 1īut-here's one of the keys to understanding what's going on-the git push step has no idea whether the remote has that tag now, and if so, what SHA-1 value it has. The rejection message you're seeing is coming from this built-in hook. Otherwise both SHA-1 values are real, valid values.Įven with no hooks, there's a sort of "built-in hook" that is also run: the remote will refuse to move a tag unless you use the "force" flag (though the "built-in hook" is always OK with both "add" and "delete"). The new-sha1 is the null SHA-1 if the tag is being deleted. The old-sha1 value is the all-zeros "null" SHA-1 if the tag is being created. Those hooks can decide whether to allow or reject the tag create/delete/update. The update request is modified by the remote to add an old-sha1 (or again, one for each tag), then delivered to the pre-receive and/or update hooks (whichever hooks exist on the remote). (Well, it sends however many: one of those for each tag.) When you ask to push tags, git push -tags sends (along with any commits and other objects needed and any other ref updates from the push settings) to the remote an update request of the form new-sha1 refs/tags/ name. ![]() ![]() Testing in Git 2.10/2.11 shows that retaining the old tag is the default behavior for clients running git fetch, and updating is the default behavior for clients running git fetch -tags. You'll need to get everyone who already has the "wrong" tag to delete their "wrong tag" and replace it with the new "right tag". So while this tells you how to do it, be really sure you want to do it. If you replace a tag on a central server, anyone who has the old tag-any clone of that central-server repository that already has the tag-could retain its old tag. Edit, : this answer is apparently popular, so I am adding a note here.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |