On Tue, Mar 05, 2013 at 07:58:45AM -0800, Junio C Hamano wrote: > > This will find anything under refs/tags, including annotated and > > non-annotated tags. I wonder if it is worth making a distinction. In > > many workflows, unannotated tags should not be leaked out to public > > repos. But because this feature finds any reachable tags, it will push a > > tag you made a long time ago as a bookmarker on some part of the history > > unrelated to the release you are making now. > > What does the auto-follow feature of "git fetch" do currently? > Whatever we do here on the "git push" side should match it.
It fetches anything in refs/tags, unannotated or not. And that is certainly a point in favor of "git push" doing the same. But I wonder if fetching and pushing are different in that respect. You are (usually) fetching from a public publishing point, and it is assumed that whatever is there is useful for sharing. The only reason to limit it is to save time transferring objects the user does not want. But for "push", you are on the publishing side, which usually means you need to be a little more careful. It is not just an optimization; it is about deciding what should be shared. You do not want to accidentally push cruft or work in progress in your private repository. I think it's the same logic that leads us to fetch "refs/heads/*" by default, but only push "matching" (or more recently "HEAD"). > If somebody wants to add some form of filtering mechanism based on > the tagname (e.g. '--auto-follow-tags=v[0-9]*'), I would not have a > strong objection to it, but I think that is something we should do > on top and consistently between fetch and push. I am not thrilled > by the idea of conflating annotated-ness and the public-ness of > tags. I don't like it either. But I also don't want to introduce a feature that causes people to accidentally publish cruft. It may not be a problem in practice; I'm just thinking out loud at this point. -Peff -- 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
