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

Jeff King [off-list ref] writes:

Should this be called "--follow-tags"? That makes more sense to me, as
you are catching all tags.

Perhaps.  We are sending all zero-or-more relevant tags, so I agree
that plural form is more appropriate.  I have a doubt about
"follow", though; inertia made me use "follow", but I am not sure
what we are following.  We certainly are not following tags.  If
anything, we are making tags to piggy back on the history being
pushed.

For consistency, should this match the naming of git-fetch's
options (or vice versa)? There we have:

  <default>: auto-follow tags

  --tags: fetch all of refs/heads/tags

  --no-tags: do not auto-follow

I think that naming has caused some confusion in the past.

"--tags" does not belong in the discussion of "auto following".  It
does not have to do with any "auto"-ness.  Renaming "--no-tags" to
"--no-follow-tags" does make sense, though.

And there is no way to explicitly specify the default behavior. I
wonder if both should support:

  --follow-tags: auto-follow tags

  --no-follow-tags: do not auto-follow tags

Yup, I like that.  Perhaps make "--no-tags" a deprecated synonym to
the latter.

  --tags: fetch/push all of refs/heads/tags

  --no-tags: turn off auto-following, and cancel any previous --tags

Sounds sensible.

The default for push should probably keep auto-follow off, though.

quoted

+--follow-tag::
+	Push all the refs that would be pushed without this option,
+	and also push the refs under `refs/tags` that are missing
+	from the remote but are reachable from the refs that would
+	be pushed without this option.
+

This reads OK to me, though it is a little confusing in that there are
two sets of refs being discussed, and "the refs that would be pushed
without this option" is quite a long noun phrase (that gets used twice).

Yes, exactly why I said I do not like the phrasing of this one.

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.

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.

Thanks.

On Tue, Mar 05, 2013 at 07:58:45AM -0800, Junio C Hamano wrote:

quoted

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