Making "hg push -r foo" changes phases

[Jordi Gutiérrez Hermoso]

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.