The phase of the pending commit depends on the parent of the working directory
and on the phases.newcommit configuration.
First, this information rather depend on the commit line which describe the
pending commit.
Then, we only want to be advertised when the pending phase is going to be higher
than the default new commit phase.
So the format will change from
$ hg summary
parent: 2:ab91dfabc5ad
foo
parent: 3:24f1031ad244 tip
bar
branch: default
commit: 1 modified, 1 unknown, 1 unresolved (merge)
update: (current)
phases: 1 secret (secret)
to
parent: 2:ab91dfabc5ad
foo
parent: 3:24f1031ad244 tip
bar
branch: default
commit: 1 modified, 1 unknown, 1 unresolved (merge) (secret)
update: (current)
phases: 1 secret
The number of draft and secret changesets are currently not summarized.
This is an important information because the number of drafts give some rough
idea of the number of outgoing changesets in typical workflows, without needing
to probe a remote repository. And a non-zero number of secrets means that
those changeset will not be pushed.
If the repository is "dirty" - some draft or secret changesets exists - then
summary will display a line like:
phases: X draft, Y secret (public)
The phase in parenthesis corresponds to the highest phase of the parents of
the working directory, i.e. the current phase.
By default, the line is not printed if the repository is "clean" - all
changesets are public - but if verbose is activated, it will display:
phases: (public)
On the other hand, nothing will be printed if quiet is in action.
A few tests have been added in test-phases.t to cover the -v and -q cases.
This just copies the same local sample hgrc, except it sets the
default path to the repo it was cloned from.
This is cut-and-paste from the local sample hgrc, but I think it's
acceptable, since the two pieces of code are right next to each other
and they're small. There is danger of them going out of synch, but it
would complicate the code too much to get rid of this C&P.
I also add ui as an import to hg.py, but with demandimport, this
should not be a noticeable performance hit.
Some users clone from a server before ever running 'hg config --edit',
so they don't see our helpful template for things like enabling the
username. Attempt to give them some helpful guidance.
Before this patch, "commonincoming" calculated by
"discovery.findcommonincoming()" is cleared, only if "default" URL
without branch part (tail "#branch" of URL) differs from
"default-push" URL without branch part.
But common revisions in "commonincoming" calculated for a branch
doesn't include ones for another branch, even if URLs without branch
part are same. The result of "discovery.findcommonoutgoing()"
invocation with such "commonincoming" becomes incorrect in some cases.
This patch clears "commonincoming", also if branch part of "default"
differs from one of "default-push".
To avoid redundant looking up:
- "ui.expandpath('default')" and "ui.expandpath('default-push',
'default')" are not compared directly, even though they contain
branch information, because they are not yet normalized by
"hg.parseurl()": tail "/" of path, for example
- "commonincoming" is not cleared, if branch isn't specified in
"default" URL, because such "commonincoming" contains common
revisions for all branches
This patch also tests "different path, same branch" pattern to check
careless degrading around comparison between source and destination.
Before this patch, "incoming" information of "hg summary --remote" is
not sensitive to the branch specified in the URL of the destination
repository, even though "hg pull"/"hg incoming" are so.
Invocation of "discovery.findcommonincoming()" without "heads"
argument treats revisions on branches other than the one specified in
the URL as incoming ones unexpectedly.
This patch looks head revisions, which are already detected by
"hg.addbranchrevs()" from URL, up against "other" repository, and
invokes "discovery.findcommonincoming()" with list of them as "heads"
to limit calculation of incoming revisions.
Before this patch, "outgoing" information of "hg summary --remote" is
not sensitive to the branch specified in the URL of the destination
repository, even though "hg push"/"hg outgoing" are so:
Invocation of "discovery.findcommonoutgoing()" without "onlyheads"
argument treats revisions on branches other than the one specified in
the URL as outgoing ones unexpectedly.
This patch looks head revisions, which are already detected by
"hg.addbranchrevs()" from URL, up against local repository, and
invokes "discovery.findcommonoutgoing()" with list of them as
"onlyheads" to limit calculation of outgoing revisions.
Many tests didn't change back from subdirectories at the end of the tests ...
and they don't have to. The missing 'cd ..' could always be added when another
test case is added to the test file.
This change do that tests (99.5%) consistently end up in $TESTDIR where they
started, thus making it simpler to extend them or move them around.
Currently we have the following return codes if nothing is found:
commit incoming outgoing pull push
intended 1 1 1 1 1
documented 1 1 1 0 1
actual 1 1 1 0 1
This makes pull agree with the rest of the table and makes it easy to
detect "nothing was pulled" in scripts.
Globbing is usually used for filenames, so on windows it is reasonable and very
convenient that glob patterns accepts '\' or '/' when the pattern specifies
'/'.
Some errors could leave self.urlopener uninitialized and thus cause strange
crashes in __del__.
This member variable is now "declared statically" and checked for assignment
before use.
If the working dir parent was destroyed by rollback, then the old
behaviour is perfectly reasonable: restore dirstate, branch, and
bookmarks. That way the working dir moves back to an existing
changeset rather than becoming an orphan.
But if the working dir parent was unaffected -- say, you updated to an
older changeset and then did rollback -- then it's silly to restore
dirstate and branch. So don't do that. Leave the status of the working
dir alone. (But always restore bookmarks, because that file refers to
changeset IDs that may have been destroyed.)
Previously, when rolling back a transaction, some users could be confused
between the level to which the store is rolled back, and the new parents
of the working directory.
$ hg rollback
rolling back to revision 4 (undo commit)
With this change:
$ hg rollback
repository tip rolled back to tip revision 4 (undo commit)
working directory now based on revision 2 and 1
So now the user can realize that the store has been rolled back to an older
tip, but also that the working directory may not on the tip (here we are
rolling back the merge of the heads 2 and 1)
When issuing `hg pull -r REV` in a repo with no common ancestor with the
remote repo, the message 'requesting all changes' is printed, even though only
the changese that are ancestors of REV are actually requested. This can be
confusing for users (see
http://www.selenic.com/pipermail/mercurial/2010-October/035508.html).
This silences the message if (and only if) the '-r' option was passed.
This adds a " (glob)" marker that works like a simpler version of
(re): "*" is converted to ".*", and "?" is converted to ".".
Both special characters can be escaped using "\", and the backslash
itself can be escaped as well.
Other glob-style syntax, like "**", "[chars]", or "[!chars]", isn't
supported.
Consider this test:
$ hg glog --template '{rev}:{node|short} "{desc}"\n'
@ 2:20c4f79fd7ac "3"
|
| o 1:38f24201dcab "2"
|/
o 0:2a18120dc1c9 "1"
Because each line beginning with "|" can be compiled as a regular
expression (equivalent to ".*|"), they will match any output.
Similarly:
$ echo foo
The blank output line can be compiled as a regular expression and will
also match any output.
With this patch, none of the above output lines will be matched as
regular expressions. A line must end in " (re)" in order to be matched
as one.
Lines are still matched literally first, so the following will pass:
$ echo 'foo (re)'
foo (re)
