My idea is to add functionality to git-remote to prune stale tags (those which no longer exist on the remote). Add a new ui: git remote prune --tags [-n | --dry-run] <name> [<remote>] I think it is not possible to know which remote tags originated from, yes? That's why I suggested adding the [<remote>] parameter; one would be required to specify the remote to sync with if more than one remote is configured. Potential use cases: * tags change from time to time * accidentally push a tag with the wrong name * accidentally push a tag with secret information * tag naming convention changes (1.0, 1.1, 2.0 -> v1.0, v1.1, v2.0) ...and someone else pulled these "bad" tags, someone that may need to do "git push --tags" sometime in the future. The only workaround I'm aware of in this situation is to try to alert everyone with clones who may eventually need to run "git push --tags" to manually delete specific tags from their clones. I acknowledge that the use cases are probably contrived/uncommon. Yes, tags are meant to be forever. But mistakes happen, and maybe not everyone uses tags the way they were anticipated to be used. Maybe there's already a suitable workaround better than asking everyone to manually delete tags? If so, please let me know. I'd rather do that than advocate adding more complexity to git. Here is a *little* evidence that I'm not the only one with this silly idea. Here's a thread on stackoverflow covering the first use case above (tags change from time to time): http://stackoverflow.com/questions/1841341/git-remove-local-tags-that-are-no-longer-on-the-remote-repository And these look like custom scripts to "sync" local tags with those on a remote: https://github.com/kigster/git_scripts/blob/master/bin/git-sync-local-tags https://gist.github.com/345031 Thoughts? -- 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