Some initial impressions of phases
mpm at selenic.com
Tue Jan 24 13:30:19 CST 2012
On Tue, 2012-01-24 at 19:25 +0100, Jason Harris wrote:
> On Jan 24, 2012, at 5:47 PM, Matt Mackall wrote:
> > On Tue, 2012-01-24 at 09:14 +0100, Jason Harris wrote:
> >> 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.)
> > No, I'm thinking of tag/tags.
> >> 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?
> > Several, actually. Consider update and export. It's there so that people
> > who get in the habit of using -r don't get bitten when a command expects
> > a rev without a -r.
> Well update can't take a range
Incorrect. Just about all commands now take revsets and thus now
implicitly support ranges.
> , and I have always found export a tiny bit odd
> that the file spec is -o. It reverses what bundle does, and arguably if I had
> been around at the time I would have argued that we should have more modeled the
> signature of export on the signature of bundle. etc. But anyway that's water
> under the bridge.
> What isn't yet water under the bridge is the signature of phase.
> Ie which of the following is more consistent with the other commands
> which take or operator on ranges:
> (a) hg phase --force --draft 970:tip
> (b) hg phase --force --rev 970:tip draft
Both are valid, and both are documented as being valid:
hg phase [-p|-d|-s] [-f] [-r] REV...
> >> 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(™).
> > The price of admission to this conversation is:
> > http://mercurial.markmail.org/search/?q=local%20clone%20phase
> >>>> 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.)
> > You are wrong about commit and revert. Lots of commands are silent on
> > success, it's the default stance.
> I thought I had tested commit. Maybe I some option set or something... But in any case
> revert seems to print a message upon reverting stuff:
> Last login: Tue Jan 24 16:32:49 on ttys000
> [salt:~] $ mkdir hgtest
> [salt:~] $ cd hgtest
> [salt:~/hgtest] $ echo a > a
> [salt:~/hgtest] $ hg init
> [salt:~/hgtest] hgtest $ hg commit -A -m "initial commit"
> adding a
> [salt:~/hgtest] hgtest 0(0) $ echo b >>a
> [salt:~/hgtest] hgtest 0(0) $ hg commit -A -m "second commit"
> [salt:~/hgtest] hgtest 1(1) $ hg revert --all --rev 0
> reverting a
> [salt:~/hgtest] hgtest 1(1) $ hg version
> Mercurial Distributed SCM (version 2.0.2+20120104)
> So it seems like revert does report stuff.
It reports non-explicitly mentioned filenames, just like add, addremove,
and commit -A.
> >>> 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.
> > Realistically, for every person writing a fancy GUI client like you,
> > there are 100 sysadmins who are parsing this output with grep and perl
> > in the dumbest possible way for a cron job. This is the target audience
> > of CompatibilityRules, not you.
> Maybe. But more importantly as a way forward, what about the idea of
> "hg log --style modern" which people can then set in their hgrc,
> or maybe something else which "just does the right thing"?
Aside: never name anything "modern" unless you're being preemptively
> Even if it's not the default having some simple and convenient way to get
> log results with phases would be nice. (Of course if not then some thousands of
> mercurial users world wide will start to investigate rolling there own --template
> if they know about this option to log...)
I think you're missing something here: I really don't want you to even
be aware of phases on a day-to-day basis. Thus having it shown in the
log via any sort of default is just not interesting to me. They should
only be of interest to people who are rewriting history while breaking
the implicit rules on rewriting history.
Yes, we can add a style, see the recently added bisect style. I'm not in
a hurry to do that.
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel