Making "hg push -r foo" changes phases

[Angel Ezquerra]

On Mon, Jun 17, 2013 at 6:19 PM, Jordi Gutiérrez Hermoso
<jordigh at octave.org> wrote:
> 1On 17 June 2013 10:14, Nikolaj Sjujskij <sterkrig at myopera.com> wrote:
>> Den 2013-06-17 17:48:12 skrev Jordi Gutiérrez Hermoso <jordigh at octave.org>:
>>
>>
>>> On 17 June 2013 09:24, 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.
>>>
>>> How do you create secret changesets without --force?
>>
>>  I fail to see what it has to do with anything I wrote ("regarding
>> pushing secret changesets").
>
> I'm trying to discover your secret phase workflow that doesn't involve
> forcing, and how you are pushing them.
>
>>>>> 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 .
>>>
>>> Again, if I'm teaching hg to other people, telling them to create
>>> magic aliases is wrong.
>>
>>  Why are magic commands/options better?
>
> Because phases add cognitive load, as does adding secret sauces to
> .hgrc. I'll have to begin by explaining what an alias is, explain what
> ! means, what is $HG, what are phases, and why the -fs options are
> necessary.
>
> Instead, I should be able to tell them, "if you don't want to share a
> commit yet, make it --secret when you commit it,", and that's all. The
> actual phase mechanism that makes this possible should be mostly an
> implementation detail or something that needs to be messed with only
> in advanced cases, e.g. when you made a big mistake.
>
> When they want to actually share their secret commit(s), I may have to
> explain phases then, since I don't think push should grow a
> --push-secret option.
>
>>>>> 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.
>>>
>>> There's a good reason why that needs force, because that's kind of the
>>> whole point of phases. They record what has already been shared, and
>>> they record this automatically. If you want to override the default
>>> mechanism and tell hg, "no, wait, this wasn't really shared despite
>>> what you think", then that should require a force. Hg needs to be able
>>> to automatically track phase status.
>>
>>  Are you sure you've understood me correctly?
>
> Are you sure you've understood me?
>
> The reason why draft->secret requires a force is that drafts can be
> shared between non-publishing repos. It's a kind of sharing that isn't
> as widespread as a public repo, but it's still sharing. If you push a
> secret phase to a non-publishing repo, it is now a draft, and it
> should stay this way.
>
> - Jordi G. H.

I don't think that is a very strong reason to require a --force option
for the draft-secret phase transition.

It is true that draft revisions can be shared, but they are still
mutable. Making a public changeset draft is dangerous because then
mercurial will let you modify it (e.g. though amend, etc) where you
could not modify it when it was public. Making a draft revision secret
does not let you do things that you could not do before since draft
revisions are already mutable.

Angel