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

From: Jeff King <peff@peff.net>
Date: Jun 7, 2011, 17:30 UTC
Message-ID: <20110607173051.GA22216@sigill.intra.peff.net>
In-Reply-To: <7v4o417g9s.fsf@alter.siamese.dyndns.org>

On Tue, Jun 07, 2011 at 09:33:35AM -0700, Junio C Hamano wrote:

Show 14 quoted lines

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

Hmm. Is it a clear enough hint when the user uses an actual tag object to make a signed or annotated tag? At least for me, private throw-away tags tend to just be refs/tags/foo pointing to a commit, and real, for-public-consumption tags at least get an annotation, if not a signature.

I seem to recall we make a similar distinction somewhere else in the code, but I can't remember offhand where. Maybe it was just a proposal that never made it anywhere.

Anyway, the problem would be somebody who does something like:

  $ git tag -m "here is a description of how this wip is going" foo-wip

which violates the assumption above. I have no idea how common that is (I tend to write such descriptions into a WIP commit message, and if I really want to, tag the resulting commit directly).

-Peff