Currently, we don't delete tags from our clone, and neither does git fetch --prune. After doing a fetch, we should enumerate local and remote tags and remove any local tags that are no longer present in the remote.
Description
Description
Related Objects
Related Objects
- Mentioned In
- Z1336: General Chat
- Mentioned Here
- T6878: Tagged commits which are not ancestors of any branch head don't get imported
Event Timeline
Comment Actions
According to this:
http://stackoverflow.com/a/16311126/821226
...we can do:
git fetch <remote> --prune --tags
...but only in "recent" versions of Git.
Comment Actions
I merged https://github.com/phacility/phabricator/issues/679 here, which discusses a similar issue with hosted repositories. We're probably not cleaning up ref cursors properly, or not filtering them properly in the UI.
Comment Actions
See also https://github.com/phacility/phabricator/issues/711. That report deals with reusing a callsign, and the new version of the repository picking up leftovers from the old repository.
I think we err on the side of caution when running bin/remove destroy and do not remove the working copy itself, but we should consider something like warning the user about this or moving it aside. This is made slightly complicated because DestructibleInterface does not currently have a way to transport warnings to the user about leftover resources.
Comment Actions
I believe this was resolved by T6878 or related work. In the modern codebase, we fetch with --prune and explicit refspecs, which is sufficient according to git help fetch:
--prune: ... However, if tags are fetched due to an explicit refspec (either on the command line or in the remote configuration, for example if the remote was cloned with the --mirror option), then they are also subject to pruning.
Locally, I deleted a tag in an observed remote and saw it properly deleted in the local working copy after an update, so this appears to hold empirically.