On Thu, Jun 5, 2014 at 3:50 PM, Junio C Hamano <gits...@pobox.com> wrote: > 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. > >> This is not only wasteful, but dangerous. I might accidentally delete >> a local tag I haven't pushed yet... > > 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 ;-) > <snip>
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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
