Adam MonsenMy 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?
