Re: [PATCH 2/2] push: --follow-tag

[Jeff King <peff@peff.net>]

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