Making "hg push -r foo" changes phases

Angel Ezquerra angel.ezquerra at gmail.com
Mon Jun 17 10:10:48 CDT 2013


On Mon, Jun 17, 2013 at 3:24 PM, Nikolaj Sjujskij <sterkrig at myopera.com> wrote:
> Den 2013-06-14 22:32:30 skrev Jordi Gutiérrez Hermoso <jordigh at octave.org>:
>
>> On 14 June 2013 14:25, Nikolaj Sjujskij <sterkrig at myopera.com> 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.

Cheers,

Angel


More information about the Mercurial-devel mailing list