[rfd] auto-following tags upon "git push"?

It has been a very conscious design decision that "git push" does not push tags without being told, as opposed to "git fetch" that can fetch tags that point at commits that are being transferred.

The rationale is quite obvious, once you think about it. When fetching, you are interacting with a remote repository somebody has published, which means two important things: (1) the set of tags that exist there are all the publisher wanted people to see, and (2) not only you but other people will also see the same tags. In other words, tags in repositories you fetch from are designed to be public and shared. It will facilitate communication between developers if it is easy for everybody to fetch these same tags.

When pushing, you are pushing from your working repository, which most of the time is not public, and tags in that repository is not designed to be public. You can use your own local tags to mark your progress, so it does not make sense to blindly push all tags in your repository to the repository you are pushing to publish your changes, whose tags are by definition public.

	Side note: the same logic applies to pushing branches. The
	branches in the remote you fetch from are public, the ones in your
	repository are mixture of branches for your private work and
	branches for public consumption.

So the recommended workflow for publishers has always been:

 - work on private topic branches that do not have corresponding branches
   at the publishing repository to cook your work-in-progress;

 - integrate them when they are done to branches that do have
   corresponding branches at the publishing repository;

 - "git push" without any extra configuration will push "matching"
   branches, so that your private topic branches will stay private, and
   the integration branches used to communicate with everybody else will
   be pushed;

 - You can use a private tag to mark your point if you want to, and
   you can tag a release on a branch that is shared with public.

 - A new branch, or a new tag to be made public needs to be pushed
   explicitly. Requiring an explicit push, instead of blindly pushing
   everything, avoids contaminating the ref namespace of the public
   repository with your private topic branches and private tags by
   accident.

But we could do better.

Tags are designed to promote sharing of common reference points; the goal is to ensure that within the scope of a project, when somebody says v1.0 is buggy, everybody else knows exactly which version v1.0 refers to (this is the primary reason why we do not use separate-remote layout for tags).

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.

So, while we still should _never_ automatically push any tag that points at a commit that is being pushed out (i.e. inverse of "fetch" that auto follows tags), if the user or the project can give a clear enough hint to git which tags are for public consumption, we should at least be able to push tags that are for public consumption and do point at commits that are being pushed out.

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*.*.*'

   Usual development process.
   $ git checkout master
   $ work work work

   Not very happy as the result is a mess, but it seems to work Ok.
   $ git tag wip

   Try it again with the wisdom gained from the previous attempt.
   $ rework rework rework

   How much improvement did we make? Hmm, looks good.
   $ git diff wip

   Use that for the release.
   $ 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