Making "hg push -r foo" changes phases

Laurens Holst laurens.nospam at grauw.nl
Mon Jun 17 10:19:23 CDT 2013


Op 17-06-13 15:24, Nikolaj Sjujskij schreef:
>>>  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 there’s value in making secret phases more intuitive to use.

I agree however that pushing secret phases should never be done without 
explicitly saying so. As Augie noted, there are many ways in which you 
could accidentally push a changeset in the secret phase, even when 
specifying a sha or bookmark pointing to a secret changeset. Using the 
hg phase command seems like the right venue for that explicit consent.

>> 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 .

If you’re looking for an alias, this is the one you should be using:

[alias]
secommit = !$HG commit --config new-commit=secret $a

This creates the commit in the secret phase directly.

However personally I think having a --secret flag on commit makes a lot 
of sense. I think in the past Matt made some objections based on fear 
for option overload. Nevertheless... if you ask me convenience trumps 
here. And commit has room for one more option, I think.

(And before the argument pops up: no, that doesn’t automatically mean we 
need to have --draft and --public options as well. A --secret option 
addresses a common action in a normal workflow. Whereas going from draft 
to public happens automatically, and won’t ever need to be --forced 
either. And in case someone configured new-commit to be public, well, 
the current method is still available, and he’s already aware of the 
configuration setting.)

>> 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 think it had something to do with phases being designed to move 
upwards only (and the phase exchange protocol working based on this 
assumption). So if you’ve already shaded such draft phase (even 
locally), moving the phase down won’t work.

But if the commit is not created as draft in the first place, forcing is 
not necessary. The need to use --force is a symptom of a problem instead 
of the problem itself.

~Laurens


More information about the Mercurial-devel mailing list