idea: pruning stale tags

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?

On 11-03-10 12:10 PM, Adam Monsen wrote:

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.

I agree with this idea, but in the context of Johan's proposed overhaul of
ref namespaces:

http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=165885

		M.