A buggy __version__ content (usually from setup.py's hg being unable to read the
repo) can make this test fails in an obscure manner. We make the root of the
failure more explicit.
Mercurial uses a synopsis string and the docstring of a command for the
command's help output. Today there is no way for an extension that adds
functionality to a command to extend either of these help strings.
This patch enables appending to both the doctring and the synopsis, and adds
a test for this functionality. Example usage is shown in the test and is also
described in the docstring of extensions.wrapcommand().
Extensions can declare compatibility with Mercurial versions. If an
error occurs, Mercurial will attempt to pin blame on an extension that
isn't marked as compatible.
While all bets are off when it comes to the internal API, my experience
has shown that a monthly/patch release of Mercurial has never broken any
of the extensions I've written. I think that expecting extensions to
declare compatibility with every patch release of Mercurial is asking a
bit much and adds little to no value.
This patch changes the blame logic from exact version matching to only
match on the major and minor Mercurial versions. This means that
extensions only need to mark themselves as compatible with the major,
quarterly releases and not the monthly ones in order to stay current and
avoid what is almost certainly unfair blame. This will mean less work
for extension authors and almost certainly fewer false positives in the
blame attribution.
In the dropped example, the extension would look for 'vdiff.diffargs' in the
configuration, and not finding it, would run kdiff3 without the configured
options. That's not obvious to a new user who sees a kdiff3 configuration in
the prepackaged mergetools.rc file, and sees that kdiff3 still runs. While it
is conceivable that the user wants a kdiff3 command that runs without the
preconfigured options, it is more likely what they want is this, which uses the
canned options:
[alias]
vdiff = kdiff3
[extdiff]
kdiff3 =
We could mention alias here, but that seems like it belongs elswhere.
There are three ways to configure an extdiff tool:
1) cmd.tool = (/path/to/exe optional)
2) tool = (path/to/exe optional)
3) tool = sometool someargs
Previously, if no executable is specified in the first two forms, the named tool
must be in $PATH, or the invocation fails. Since the [merge-tools] section
already has the path to the diff executable, and/or the registry keys to find
the executable on Windows, reuse that configuration for forms 1 and 2 instead of
failing. We already fallback to [diff-tools] and then [merge-tools] for program
arguments if they aren't specified in the [extdiff] section.
Since this additional lookup only occurs if an executable is not on the $PATH
for the named tool, this is backwards compatible. For now, we assume the user
knows what he is doing if a path is provided.
This change allows a configuration file like this (assuming beyondcompare3 is
configured in merge-tools), instead of hardcoding system specific a path:
[extdiff]
beyondcompare3 =
We used to have two slightly different message which people wouldn't read...
and then complain that they couldn't find the global options or examples.
So we unify them into one message that's upfront that STUFF IS
INTENTIONALLY HIDDEN and that looks more like our normal hint style.
When `hg help foobar` fails, it now suggests using `hg help --keyword foobar`
instead of printing a full page of basic commands.
This should greatly increases discoverability of the `hg help --keyword`
argument.
On MinGW environment, the command line below in test script can't
extract wildcard "*" and remove target files correctly.
$ rm $ENVVAR/foo/bar.*
To extract wildcard, environment variable should be quoted by double
quotation like below:
$ rm "$ENVVAR"/foo/bar.*
This patch also omits "-f" of "rm" to know whether files are removed
or not by exit code of it.
Before this patch, test code introduced by becb9079df52 into
test-extension.t always uses ":" as the path separator in PYTHONPATH.
But ";" should be used on Windows.
This patch chooses the path separator in PYTHONPATH suitable for
platform.
Before this patch, python modules of each extensions can't import
another one in own extension by absolute name, because root modules of
each extensions are loaded with "hgext_" prefix.
For example, "import extroot.bar" in "extroot/foo.py" of "extroot"
extension fails, even though "import bar" in it succeeds.
Installing extensions into site-packages of python library path can
avoid this problem, but this solution is not reasonable in some cases:
using binary package of Mercurial on Windows, for example.
This patch retries to import with "hgext_" prefix after ImportError,
if the module in the extension may try to import another one in own
extension.
This patch doesn't change some "_import()"/"_origimport()" invocations
below, because ordinary extensions shouldn't cause such invocations.
- invocation of "_import()" when root module imports sub-module by
absolute path without "fromlist"
for example, "import a.b" in "a.__init__.py".
extensions are loaded with "hgext_" prefix, and this causes
execution of another (= fixed by this patch) code path.
- invocation of "_origimport()" when "level != -1" with "fromlist"
for example, importing after "from __future__ import
absolute_import" (level == 0), or "from . import b" or "from .a
import b" (0 < level),
for portability between python versions and environments,
extensions shouldn't cause "level != -1".
Before this patch, demandimport of Mercurial may fail to load external
libraries using "from __future__ import absolute_import": for example,
importing "foo" in "bar.baz" module will load "bar.foo" if it exists,
even though "absolute_import" is enabled in "bar.baz" module.
So, extensions for Mercurial can't use such external libraries.
This patch saves "level" of import request for on-demand module
loading in the future: default value of level is -1, and level is 0
when "absolute_import" is enabled.
"level" value is passed to built-in import function in
"_demandmod._load()" and it should load target module correctly.
This patch changes only one "_demandmod" construction case other than
cases below:
- construction in "_demandmod._load()"
this code path should be used only in relative sub-module
loading case
- constructions other than patched one in"_demandimport()"
these code paths shouldn't be used in "level != -1" case
Strip will lives in its own extension. The extension is surprisingly called
`strip`. (as discussed in issue3824) The `mq` extension force the use of the
strip extension when its enabled. This will both necessary for backward
compatibility (people expect `mq` to comes with strip) and become some utility
function used by `mq` will move in the strip extension.
Before this patch, "extensions.extensions()" always lists up all
loaded extensions. So, commands handling multiple repositories at a
time like below enable extensions unexpectedly.
- clone from or push to localhost: extensions enabled only in the
source are enabled also in the destination
- pull from localhost: extensions enabled only in the destination
are enabled also in the source
- recursive execution in subrepo tree: extensions enabled only in
the parent or some of siblings in the tree are enabled also in
others
In addition to it, extensions disabled locally may be enabled
unexpectedly.
This patch checks whether each of extensions should be listed up or
not, if "ui" is specified to "extensions.extensions()", and invokes
"reposetup()" of each extensions only for repositories enabling it.
The dispatch code now enables filtering of "hidden" changesets globally. The
filter is installed before command and extension invocation. The `--hidden`
switch is now global and disables this filtering for any command.
Code in log dedicated to changeset exclusion is removed as this global filtering
has the same effect.
When extensions had an empty `testedwith` attribute the code tried to parse it
and failed. As a result the actual error were shallowed by a This crash.
We now treat empty strip as 'unknown'
Before this patch, there is no information about whether help document
is fully displayed or not.
So, some users seem to misunderstand "-v" for "hg help" just as "the
option to show list of global options": experience on "hg help -v" for
some commands not containing verbose containers may strengthen this
misunderstanding.
Such users have less opportunity for noticing omitted help document,
and this may cause insufficient understanding about Mercurial.
This patch indicates help omitting, if help document is not fully
displayed.
For command help, the message below is displayed at the end of help
output, if help document is not fully displayed:
use "hg -v help xxxx" to show more complete help and the global
options
and otherwise:
use "hg -v help xxxx" to show the global options
For topics and extensions help, the message below is displayed, only
if help document is not fully displayed:
use "hg help -v xxxx" to show more complete help
This allows users to know whether there is any omitted information or
not exactly, and can trigger "hg help -v" invocation.
This patch causes formatting help document twice, to switch messages
one for omitted help, and another for not omitted. This decreases
performance of help document formatting, but it is not mainly focused
at help command invocation, so this wouldn't become problem.
The "worst" extension still is the one tested with the lowest tested version
below the current version of Mercurial, but if an extension with was only
tested with newer versions, it is considered a candidate for a bad extension,
too. In this case extensions which have been tested with higher versions of
Mercurial are considered better. This allows finding the oldest extension if
ct can't be calculated correctly and therefore defaults to an empty tuple, and
it involves less changes to the comparison logic during the current code
freeze.
This patch changes the function which generates help text about commands and
options to use RST formatting. Tables describing options have been formatted
using RST table markup for some time already, so their appearance does not
change. Command lists, however, change appearance.
To format non-verbose command lists, RST field list markup was chosen, because
it resembles the old format:
<http://docutils.sourceforge.net/docs/user/rst/quickref.html#field-lists>
In the old (hand-coded) format of non-verbose command lists, the left column is
12 characters wide. Our minirst implementation formats field lists with a left
column 14 characters wide, so this patch changes the appearance of help output
correspondingly:
<http://markmail.org/message/krl4cxopsnii7s6z?q=mercurial+reinert+from:%22Olav+Reinert%22&page=2>
The minirst markup most closely resembling the old verbose command lists is
definition lists. But using it would cause a blank line to be inserted between
each command definition, making the output excessively long, and no more
useful than before. To avoid this, I chose to use field lists also for verbose
command help, resulting in output like this example:
add add the specified files on the next commit
annotate, blame
show changeset information by line for each file
clone make a copy of an existing repository
commit, ci commit the specified files or all outstanding changes
diff diff repository (or selected files)
export dump the header and diffs for one or more changesets
forget forget the specified files on the next commit
init create a new repository in the given directory
log, history show revision history of entire repository or files
merge merge working directory with another revision
phase set or show the current phase name
pull pull changes from the specified source
push push changes to the specified destination
qdiff diff of the current patch and subsequent modifications
qinit init a new queue repository (DEPRECATED)
qnew create a new patch
qpop pop the current patch off the stack
qpush push the next patch onto the stack
qrefresh update the current patch
remove, rm remove the specified files on the next commit
serve start stand-alone webserver
status, st show changed files in the working directory
summary, sum summarize working directory state
update, up, checkout, co
update working directory (or switch revisions)
This change is a move towards generating all help text as a list of strings
marked up with RST.
Extension authors should explicitly declare their supported hg
versions and include a buglink attribute in their extension. In the
event that a traceback occurs, we'll identify the
least-recently-tested extensionas the most likely source of the defect
and suggest the user disable that extension.
Packagers should make every effort to ship hg versions from exact
tags, or with as few modifications as possible so that the versioning
can work appropriately.
The output of "hg help" is changed to ensure that the column containing
descriptions of commands, extensions, and other topics is correctly alignmened.
The default width of field lists is changed from 12 to 14 to align minirst with
the rst2html tool. Shrinking the width of the left column to fit the content is
removed, to keep formatting simple and uniform.
Globbing is usually used for filenames, so on windows it is reasonable and very
convenient that glob patterns accepts '\' or '/' when the pattern specifies
'/'.
Before, the help text said that Mercurial would assume 'yes' for all
prompts, but this is confusing since many prompts don't have any 'yes'
choice. It now more accurately describes what will happen.
The verb to allow requires a direct object.
Lintian, a Debian tool to find common mistakes, reported it. I'm not a
native english speaker but I think this is correct.
