Jeff King <peff@xxxxxxxx> 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. > >> +--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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html