On Tue, Jun 07, 2011 at 09:33:35AM -0700, Junio C Hamano wrote: > 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 -- 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