On Tue, Jun 7, 2011 at 09:33, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Which also means that there is a social convention among everybody in the > project how public tags are named. Using a tag v2.4.3 to mark your private > progress point, when the project uses tags that match "v*.*.*" to mark > public releases, is not something any sane person would do. ... > This is just me thinking out loud, but a typical end-user transcript may > look something like this: > > Tell git that v*.* and v*.*.* are release tags (one-time set-up). > $ git config --unset-all push.autotag > $ git config --add push.autotag 'v*.*' > $ git config --add push.autotag 'v*.*.*' ... > $ git tag v1.2.0 > > Push it out, with the usual matching (or "upstream") semantics plus > the new auto-follow tags feature. Note that "wip" tag will not be sent. > $ git push Questions: Does push.autotag apply to all remotes? I'm debating with myself if I really want a tag I have created locally immediately pushed to a backup repository. Just because I have tagged something on my primary work repository, doesn't mean I want that public yet. I may have temporarily tagged something, started building a release, then run a "git push backup" to send my branch tips to a private backup repository and jumped on the transit system to head home. Automatically pushing my newly created tag to my backup may be useful, but if I later move that tag before I make it public pushes to my backup might start failing. If my backup remote doesn't have a remote.backup.push refspec that includes refs/tags/* namespace, should push.autotag really send there? Does push.autotag trigger if I specify push refspecs on the command line? It probably should, as the user might have specifically configured certain refs (maint, master, next, pu, todo) to be published. Unless the user is pushing to Gerrit Code Review's magical "refs/for/*" destination namespace... in which case that tag might still only be a tentative tag and isn't really part of the project history yet. In general I agree with this idea. Its similar to the tag following we are doing on fetch/clone, and its similar to the tag visibility that Gerrit Code Review does with per-branch access controls. Unfortunately you need to configure the patterns up front. This is advanced user space. But the feature is most likely to help the new project maintainer more than an existing user. -- Shawn. -- 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