Making "hg push -r foo" changes phases

Laurens Holst laurens.nospam at
Mon Jun 17 10:21:47 CDT 2013

Op 17-06-13 17:10, Angel Ezquerra schreef:
> On Mon, Jun 17, 2013 at 3:24 PM, Nikolaj Sjujskij <sterkrig at> wrote:
>> Den 2013-06-14 22:32:30 skrev Jordi Gutiérrez Hermoso <jordigh at>:
>>> On 14 June 2013 14:25, Nikolaj Sjujskij <sterkrig at> wrote:
>>>>   By the way, have you considered using [alias]
>>>> secretpush = !$HG phase -d $@ ; $HG push -r $@
>>> I'm still trying to figure out a way to use secret phases that seems
>>> to make sense to everyone I talk to. Making everyone else use the
>>> secretpush alias seems a bit wrong.
>>   Well, I don't know. Current situation regarding pushing secret changesets
>> makes sense to me. It is simple and consistent, and you can build up on it
>> when you're sure what you want.
>>> I think a proposal I had earlier for giving commit a --secret option
>>> might make more sense. You know at the time of committing something if
>>> that something should probably not be shared yet.
>> [alias]
>> secommit = !$HG commit $a ; $HG phase -fs .
>> :)
>>> Also, going from
>>> secret to anything else doesn't require a force from hg phase, but
>>> going from anything to secret does.
>>   Yep, I agree. I se no reason why "draft -> secret" needs --force.
>> I think only manipulating with public changesets should require it.
> I agree with this. In fact we have recently changed the "warning",
> confirmation dialog that is shown by TortoiseHg when you change the
> phase from draft to secret. We used to tell the user that this was an
> operation that had to be "forced". Even the "OK" button said "Force"
> in its label. Now we have changed it (for this particular, draft to
> secret transition)  to say "Make secret". We thought that the original
> message may discourage people from using secret revisions, which I
> think is not right.
> Personally I'd prefer it if moving from draft to secret did not
> require --force, in which case we would remove the confirmation
> dialog.

I think TortoiseHg should reinstate the above mentioned warnings, 
because it needs to be forced for a reason (see my previous mail), and 
instead offer a “create secret” checkbox in the commit flow which 
commits with the --config new-commit=secret option.


More information about the Mercurial-devel mailing list