[PATCH v2] push: warn after pushing draft changesets with tags

[Matt Harbison]

On Fri, 11 Mar 2016 19:58:20 -0500, Augie Fackler <raf at durin42.com> wrote:

> On Fri, Mar 11, 2016 at 11:32:54AM -0800, Sean Farley wrote:
>>
>> Nathan Goldbaum <nathan12343 at gmail.com> writes:
>>
>> > # HG changeset patch
>> > # User Nathan Goldbaum <ngoldbau at illinois.edu>
>> > # Date 1457664319 21600
>> > #      Thu Mar 10 20:45:19 2016 -0600
>> > # Node ID 189ea0e68f3c50c28bbb060c8ef59beef43c8a8d
>> > # Parent  88738948f5d27cebe673ceb655c6161c34efda7d
>> > push: warn after pushing draft changesets with tags
>>
>> I don't know if a warning is going to be enough. After dealing with
>> users over the last year, I'm inclined to think that 'hg tag foo' should
>> just mark the tagged commit as public (or possibly the signed commit).
>
> I have a foggy memory that 'hg tag' was supposed to make the tagged
> revision public. That could be nuts though, as the context I remember
> it in was one of the sprints in Denmark.

If the simple warning isn't enough, can making the tagged revision public  
be deferred to when the tag creating changeset is pushed?

My workflow is to push to a non publishing repo regularly, tag a build  
occasionally, sanity test, and release.  Once I found a bug and needed to  
amend + evolve, and redo the build, which had its own issue [1].  If  
tagging instantly made it public, there wouldn't be any easy way to tell  
what was actually in the wild.  Even outgoing to the non publishing repo  
may not indicate that, if it is holding the draft revisions.

[1]  
https://www.mercurial-scm.org/pipermail/mercurial-devel/2015-February/066189.html

(I guess I should resubmit this patch, because even if tagging makes  
something instantly public, it can be forced back to draft and cause the  
issue in the local repo.  I just wasn't sure if Pierre-Yves' concern about  
tag caching was sufficiently addressed.)