Some initial impressions of phases

Jason Harris jason at jasonfharris.com
Tue Jan 24 02:14:55 CST 2012


On Jan 23, 2012, at 11:03 PM, Matt Mackall wrote:

>> Point 3.
>> 
>> The following is a major point and not just some nit pick.
>> 
>> Which other core mercurial command *both* changes state, and reports it using
>> the same command?
> 
> Several (such as branch and bookmark). And if I had it to do over again,
> several more.

(Were you thinking of push and pull where you would have had an option like
--show to instead get the effect of outgoing and incoming? I for one am glad
that there is no --show option. Iw Very rarely do people push when they wanted
to do outgoing but if there was the option --show I bet lots of people would
occasionally miss that option and inadvertently push stuff.)

I had forgotten about these since I normally use these through my GUI, however
even so at least with branch and bookmark one changing the primary argument of
the command. Eg

"hg bookmark" vs "hg bookmark <name>" "hg branch" vs 'hg branch <name>"

However the command to change phase is an option.

"hg phase 970:tip" vs "hg phase --draft --force 970:tip"

Actually looking at this command it's the actual revision which is the target of
the command, so  "hg phase --draft --force --rev 970:tip" can be equivalently
stated as "hg phase --draft --force 970:tip"

Does this happen with other commands? (Ie why is there a revision option to
phase at all since the revision is the primary argument which must be given in
any case right?)

(It looks like multiple revisions are supported so if you have multiple branches
in your revision tree then you can operate on them with the same command. Eg
instead of having options "hg phase --draft --force --rev spec1 --rev spec2" you
could just issue "hg phase --draft --force spec1 spec2"

This just doesn't appear nice to me. As an aesthetic thing I think separate
commands would be better. Or at least have the main argument be the phase. Eg

(a) hg phase --rev 950:tip --force private

rather than the current

(b) hg phase --force --private 950:tip

Form (a) is I believe just more "mercurial-like", eg "hg push --rev 950:tip
--force myserver", or "hg status --rev 950:tip MyDir/Classes" or qimport, etc
etc. Don't most other commands which operate on a range of revisions work in the
way (a) does?


>> Point 4.
>> 
>> How does one change the phase on commit? I thought this was meant to be an
>> option. Also there appears to be no mention of a phase option to any of clone,
>> push, pull, outgoing, incoming, etc. I had gathered that there was meant to be
>> something more on other commands?
>> 
>> Eg I had thought one might be able to do "hg commit --draft <files>"...
> 
> Deferred. Phases are designed to "just work" without you having to mess
> with them (or even being aware of them). The above is messing with them.
> Commits are draft by default, no messing needed.

It is nice that commits are draft by default. So the common workflow of being
able to commit stuff work with it, and then upon pushing note that it's public
and you have to do something to alter the history is almost there. The one thing
missing is still local clones, don't preserve the draft phase.

So currently people working all within the one tree will be ok. People working
with clones won't have phase generally doing the right thing(™).

>> -----------
>> 
>> Point 6.
>> 
>> Is there any way to qimport some revisions and change their status all within
>> one command. --force didn't do so. Of course I can trivially roll my own command
>> here and maybe we want to force the user to enter two commands in a row? Still I
>> was surprised --force didn't do this. Maybe this is more of a discussion point
>> than an outright problem.
> 
> No, intentionally. Phases are not supposed to ratchet backwards. So if
> you need to go backwards (ie qimporting a public changeset), you have to
> manually un-public it. But, by definition, you shouldn't be doing that.

People will do this all the time since eg cloning a repository locally which is draft will
currently change it to public. And then I will go to my clone, try and import it to change
something etc., curse under my breath and then change the phase, and then import it.


>> Point 8.
>> 
>> No relevant information is reported upon success:
> 
> Welcome to Mercurial. Use -v.

Hmmm... Aside from the snide response, I had felt through usage that normally
mercurial reports something on success. Maybe it's just I use those commands
more often that report something.

In a quick survey of the commands, I noticed the following commands don't report
anything bookmark, tag, add, forget. In fact bookmark doesn't even report
anything even with -v, whereas tag, add, and forget report something with -v.

However, Commit, Clone, push, pull, rollback, update, branch, and revert do
report information. (Obviously commands like Incoming, outgoing, log, status,
etc report information.)

If there is a definite pattern here I am not seeing it... It's a new command and
it's generally something "dangerous" so shouldn't something be reported here by
default. Too much feedback is of course spammy, but giving no feedback that
anything happened whatsoever for an operation which others are considering as
dangerous is not IMHO the best thing.

> 
>> Point 9.
>> 
>> The phase of the changeset when it differs from public is not reported by default.
>> [salt:.../MacHgClone14] MacHgClone14 972(972) $ rhg log --rev 968:tip
> 
> http://mercurial.selenic.com/wiki/CompatibilityRules#Commands (see what
> it says about log in particular).

Fair enough, (although almost anyone that parses this output will use a --template option...)
Still that's fine.

> For now, if you need this information (and most users do not, by
> design), then you can do 'hg log --debug' or 'hg log -r "not public()"'.

Maybe once the documentation is written there will be a suggested default
template option in the documentation for log and some other commands. --debug
gives too much information.

Maybe we can define template styles say "modern2.1"  and "modern".  "modernX.Y"
will be the style including all of the changes up to version X.Y and "modern"
will always be the most modern style so one can just say:

hg log --style modern2.1   (get the recommended style as of hg 2.1)

hg log --style modern (get the recommended style as of the current version of
hg)

Then you could set this in your hgrc:
[ui]
style = modern

See http://hgbook.red-bean.com/read/customizing-the-output-of-mercurial.html

(Actually when I use the command line -- which isn't all that often -- I sometimes
use:

glog = --template '\033[1;35m{rev}\033[0m:{node|short} {tags} \033[0;36m{desc|firstline}\033[0m\n\n'

It would be nice to have a similar command that could color the description a
subtle shade according to the phase. What would be the best way to do this?)


>> Point 10.
>> 
>> This still has public < draft < secret. Wasn't it decided to use private rather than secret?
> 
> Well, the choice was public/draft/secret + short opts or
> public/draft/private + only long opts. Since insufficient enthusiasm was
> expressed for the latter, we're sticking with the former.

What? I thought most everyone commenting on email preferred the second one, or they had
a different opinion. Some people wanted different names, but of the names which most people
agreed on, secret was not the preferred name. For the reasons I and others have articulated
it's a bad name.

>> Point 11.
>> 
>> A local clone resets the phase to public. It shouldn't.
> 
> Debated elsewhere, many arguments pro and against exist.

Well, I believe it's going to cause problems in practice. Local clones for experimentation are
going to be hampered with having to manually adjust the phase for each clone. At least there
should be an option like

hg clone --preserve-phases ...

Cheers,
   Jason


More information about the Mercurial-devel mailing list