Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Dec 2015 23:05:33 -0800] rev 27274
ui: add a 'stacklevel' argument to 'develwarn'
This allows helper functions (like deprecation warning) to prepare a devel
warning for higher up in the stack. The argument is named after the one in the
Python's 'warning,warn' function.
Yuya Nishihara <yuya@tcha.org> [Sun, 06 Dec 2015 14:28:35 +0900] rev 27273
import-checker: tell which symbol causes "direct symbol import"
This would be sometimes useful to understand why import-checker.py complains
about it.
Yuya Nishihara <yuya@tcha.org> [Sun, 06 Dec 2015 14:18:19 +0900] rev 27272
import-checker: allow absolute imports of sub modules from local packages
Before this patch, import-checker.py didn't know if a name in ImportFrom
statement are module or not. Therefore, it complained the following example
did "direct symbol import from mercurial".
# hgext/foo.py
from mercurial import hg
This patch reuses the dict of local modules to filter out sub-module names.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 04 Dec 2015 14:24:45 -0800] rev 27271
manifest: use 't' for tree manifest flag
We currently use 'd' to indicate that a manifest entry is a
directory. Let's switch to 't', since that's not a valid hex digit and
therefore easier to spot in the raw manifest data.
This will break any existing repos with tree manifests, but it's still
an experimental feature and there are probably only a few test repos
in existence with 'd' flags.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Dec 2015 23:06:03 -0800] rev 27270
test: update the docstring of 'test-devel-warnings.t' extension
We are testing more than just locks now.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 05 Dec 2015 17:52:50 -0800] rev 27269
setup.py: don't rewrite @LIBDIR@ when creating wheels
This is necessary to produce wheels that install properly. More
details are captured in an in-line comment.
After this patch, produced wheels can be installed via `pip install`
and appear to "just work," including on Windows.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 04 Dec 2015 00:24:48 -0800] rev 27268
setup.py: attempt to build and install hg.exe on Windows
Currently, packaging Mercurial on Windows will produce a
Scripts\hg Python script and a Scripts\hg.bat batch script. The
py2exe distribution contains a hg.exe which loads a Python
interpretter and invokes the "hg" Python script. Running a
exe directly has benefits over batch scripts because batch
scripts do things like muck around with command arguments.
This patch implements a custom "build_scripts" command which
attempts to build hg.exe on Windows. If hg.exe is built, it is
marked as a "script" file and installed into the Scripts\
directory on Windows. Since hg.exe is redundant and better than
hg.bat, if hg.exe is built, hg.bat is not installed.
Since some environments don't support compiling C programs,
we treat hg.exe as optional and catch failures building it. This
is not ideal. However, I reckon most Windows users will not be
installing Mercurial from source: they will get it from the MSI
installer or via `pip install Mercurial`, which will download a
wheel that has hg.exe in it. So, I don't think this is a big deal.
Andrew Halberstadt <ahalberstadt@mozilla.com> [Thu, 03 Dec 2015 23:01:59 -0500] rev 27267
merge.graft: add option to keep second parent
Currently merge.graft re-writes the dirstate so only a single
parent is kept. For some cases, like evolving a merge commit,
this behaviour is not desired. More specifically, this is
needed to fix
issue4389.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 05 Dec 2015 21:11:04 -0800] rev 27266
ui: support declaring path push urls as sub-options
Power users often want to apply per-path configuration options. For
example, they may want to declare an alternate URL for push operations
or declare a revset of revisions to push when `hg push` is used
(as opposed to attempting to push all revisions by default).
This patch establishes the use of sub-options (config options with
":" in the name) to declare additional behavior for paths.
New sub-options are declared by using the new ``@ui.pathsuboption``
decorator. This decorator serves multiple purposes:
* Declaring which sub-options are registered
* Declaring how a sub-option maps to an attribute on ``path``
instances (this is needed to `hg paths` can render sub-options
and values properly)
* Validation and normalization of config options to attribute
values
* Allows extensions to declare new sub-options without monkeypatching
* Allows extensions to overwrite built-in behavior for sub-option
handling
As convenient as the new option registration decorator is, extensions
(and even core functionality) may still need an additional hook point
to perform finalization of path instances. For example, they may wish
to validate that multiple options/attributes aren't conflicting with
each other. This hook point could be added later, if needed.
To prove this new functionality works, we implement the "pushurl"
path sub-option. This option declares the URL that `hg push` should
use by default.
We require that "pushurl" is an actual URL. This requirement might be
controversial and could be dropped if there is opposition. However,
objectors should read the complicated code in ui.path.__init__ and
commands.push for resolving non-URL values before making a judgement.
We also don't allow #fragment in the URLs. I intend to introduce a
":pushrev" (or similar) option to define a revset to control which
revisions are pushed when "-r <rev>" isn't passed into `hg push`.
This is much more powerful than #fragment and I don't think #fragment
is useful enough to continue supporting.
The [paths] section of the "config" help page has been updated
significantly. `hg paths` has been taught to display path sub-options.
The docs mention that "default-push" is now deprecated. However, there
are several references to it that need to be cleaned up. A large part
of this is converting more consumers to the new paths API. This will
happen naturally as more path sub-options are added and more and more
components need to access them.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 12:31:46 -0800] rev 27265
ui: pass ui instance to path.__init__
It will be used in a subsequent patch.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 11:49:02 -0800] rev 27264
ui: store pushloc as separate attribute
The magic @property is going to interfere with the ability to print
path sub-options. We only access it in one location and it is trivial
to in-line, so do that.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 05 Dec 2015 23:37:46 -0800] rev 27263
commands: add debugdeltachain command
We have debug commands for displaying overall revlog statistics
(debugrevlog) and for dumping a revlog index (debugindex). As part
of investigating various aspects of revlog behavior and performance,
I found it important to have an understanding of how revlog
delta chains behave in practice.
This patch implements a "debugdeltachain" command. For each revision
in a revlog, it dumps information about the delta chain. Which delta
chain it is part of, length of the delta chain, distance since base
revision, info about base revision, size of the delta chain, etc. The
generic formatting facility is used, which means we can templatize
output and get machine readable output like JSON.
This command has already uncovered some weird history in
mozilla-central I didn't know about. So I think it's valuable.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 24 Oct 2015 19:56:39 +0100] rev 27262
histedit: pick an appropriate base changeset by default (BC)
Previously, `hg histedit` required a revision argument specifying which
revision to use as the base for the current histedit operation. There
was an undocumented and experimental "histedit.defaultrev" option that
supported defining a single revision to be used if no argument is
passed.
Mercurial knows what changesets can be edited. And in most scenarios,
people want to edit this history of everything on the current head that
is rewritable. Making histedit do this by default and not require
an explicit argument or additional configuration is a major usability
win and will enable more people to use histedit.
This patch changes the behavior of the experimental and undocumented
"histedit.defaultrev" config option to select an appropriate base
revision by default. Comprehensive tests exercising the edge cases
in the new, somewhat complicated default revset have been added.
Surprisingly, no tests broke. I guess we were never testing the
behavior with no ANCESTOR argument (it used to fail with
"abort: histedit requires exactly one ancestor revision"). The new
behavior is much more user friendly.
The functionality for choosing the default base revision has been
moved to destutil.py, where it can easily be modified by extensions.
Yuya Nishihara <yuya@tcha.org> [Sat, 05 Dec 2015 23:50:13 +0900] rev 27261
rebase: remove extra "if" from check of collapsing named branches
Yuya Nishihara <yuya@tcha.org> [Sat, 05 Dec 2015 23:48:22 +0900] rev 27260
rebase: drop redundant functions to keep branch and graft source explicitly
All entries in extra dict are propagated by default since
88fde8db5307.
Yuya Nishihara <yuya@tcha.org> [Sat, 05 Dec 2015 23:41:11 +0900] rev 27259
color: drop useless override of ui.popbuffer()
Because labels are applied at write() time since
717b75ae5bb0,
colorui.popbuffer() is useless and it doesn't update _bufferapplylabels
correctly. Removing it should fix the problem.