Making "hg push -r foo" changes phases
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.
> secommit = !$HG commit $a ; $HG phase -fs .
If you’re looking for an alias, this is the one you should be using:
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
>> 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.
More information about the Mercurial-devel