Proposal for pruning tags

I've never contributed to the Git project before. I'm a Windows user, so I use msysgit, but I'd be happy to install linux just so I can help implement this feature if everyone feels it would be useful.

Right now AFAIK, there is no way to prune tags through Git. The way I currently do it is like so:

$ git tag -l | xargs git tag -d $ git fetch --all

This is not only wasteful, but dangerous. I might accidentally delete a local tag I haven't pushed yet. What would be great is if we had the following:

git tag prune [<remote>|--all]

The <remote> is needed in decentralized workflows (upstream vs origin). I'd also like to see an `--all` option in place of the remote, which means it will prune local tags from all remotes. I'm not sure if this command line structure will work, but it can be altered as necessary.

Alternatively, this might also make sense on the remote command:

git remote prune <remote> --tags

Again I'm not an expert at the internals of Git, so I wanted to share my idea with the community first to see if this holds water or if there is already some built in way of doing this. Thanks for hearing out my idea!

Robert Dailey <rcdailey.lists@gmail.com> writes:

I think you need to explain what you mean by "prune" a lot better than what you are doing in your message to be understood by others.

After seeing the above two commands, my *guess* of what you want to do is to remove any of your local tag that is *not* present in the repository you usually fetch from (aka "origin"), but that directly contradicts with what you said you wish, i.e.

which only shows that your definition of "prune" is different from "remove what I do not have at 'origin'".

But it does not say *how* that is different. How should "prune" behave differently from the two commands above? How does your "prune" decide a tag needs to be removed locally when it is not at your "origin" [*1*]?

There is *nothing* in git that lets you look at a local tag that is missing from the other side and determine if that is something you did not want to push (hence it is missing there) of if that is something you forgot to push (hence it is missing there but you would rather have pushed if you did not forget). So you must have some new mechanism to record and/or infer that distinction in mind, but it is not clear what it is from your message.

So until that is clarified, there is not much more to say if your "feature" has any merit---as there is no way to tell what that "feature" exactly is, at least not yet ;-)

[Footnote]

*1* By the way, removing and then refetching would be a silly way to
    do this kind of thing anyway.  After removing but before you
    have a chance to fetch, your ISP may severe your network
    connection and then what happens?

    Whatever your definition of "prune" is, I would think it would
    be built around "ls-remote --tags" output, to see what tags the
    other repository (or other repositories, by looping over the
    remotes you interact with) have, compare that set with the tags
    you locally have in order to decide which subset of tags you
    locally have to remove.

On Thu, Jun 5, 2014 at 3:50 PM, Junio C Hamano <gitster@pobox.com> wrote:

You're right I didn't clarify, although I feel you're not providing the most welcome response to someone who isn't as familiar with the internals of Git as you are.

It was an oversight on my part. What I was expecting is that it would behave exactly like branch pruning does, but that would require "remote tracking tags", which we don't have. So, apparently my idea doesn't hold much water.

The general problem I see in the day to day workflow with my team is that if tags exist locally and they push, those tags continuously get recreated on the remote repo even after I delete them remotely. So I can never truly delete tags until I go to each person and make sure the tool they're using isn't accidentally pushing tags. For example, SourceTree pushes all tags by default. Everyone on my team is new to Git, so they don't know to turn that off. Having git clean up tags automatically would really help with this, even though you may not feel it's the responsibility of Git. It's more of a usability issue, it's just prone to error.

I can setup my config to prune tracking branches after I pull. Having something like this for tags would be wonderful. However, this requires a bigger overhaul than what I initially was proposing.

Robert Dailey <rcdailey.lists@gmail.com> writes:

I agree with "Having ... help with this". I did not say at all that it is not something Git should and can try to help. I also agree with it is a usability issue.

The thing is, the word "automatically" in your "clean up tags automatically" is still too loose a definition of what we want, and we cannot come up with a way to help users without tightening that looseness. As you said, you are looking for something that can tell between two kinds of tags that locally exist without having a copy at the 'origin':

 - ones that you do not want to keep
 - others that you haven't pushed to (or forgot to push to) 'origin'

without giving the users a way to help Git to tell these two kinds apart and only remove the former.

So...

On 06/05/2014 04:51 PM, Robert Dailey wrote:

Junio explained some limitations of tags (namely that there is only one tags namespace that is shared project-wide) that makes your wish impossible to implement the way it works for branches.

Local tags are awkward for the same reason. It is too easy to push them accidentally to a central repository and too hard to delete them after that has happened. They kindof spread virally, as you have noticed. I recommend against using local tags in general.

Recent Git does have a feature that might help you. *If* you have a central repository that is "authoritative" WRT tags, then you can sync the tags in your local repository to the tags in the central repo using

    git fetch --prune $REMOTE +refs/tags/*:refs/tags/*

You might also be able to use a pre-receive hook on the central repo to prevent tags from being pushed by people who shouldn't be doing so, or to require that tags have an approved format (like refs/tags/release-\d+\.\d+\.\d+ or whatever) to try to prevent a recurrence of the problem.

Michael