Grouping all evolution related-config under the experimental.evolution
namespace would helps the future migration outside [experimental].
Differential Revision: https://phab.mercurial-scm.org/D1155
Stabilization config items were never part of a release, remove them now that
we cleaned up the evolution related configuration.
Differential Revision: https://phab.mercurial-scm.org/D1154
We want to get rid of stabilization.* configuration, back out to the old
configuration 'evolution.track-operation'.
Differential Revision: https://phab.mercurial-scm.org/D1153
We want to get rid of stabilization.* configuration, back out to the old
configuration 'evolution.bundle-obsmarker'.
Differential Revision: https://phab.mercurial-scm.org/D1152
Extract 'experimental.evolution' = exchange as
'experimental.evolution.exchange'.
We keep the new option in the 'experimental.evolution' namespace in order to
stay coherent with other options ('experimental.evolution.bundle-obsmarker'
and 'experimental.evolution.track-operation') ease the renaming as possibly
'evolution.exchange'.
Differential Revision: https://phab.mercurial-scm.org/D1151
Extract 'experimental.evolution' = allowunstable as
'experimental.evolution.allowunstable'.
We keep the new option in the 'experimental.evolution' namespace in order to
stay coherent with other options ('experimental.evolution.bundle-obsmarker'
and 'experimental.evolution.track-operation') ease the renaming as possibly
'evolution.allowunstable'.
Differential Revision: https://phab.mercurial-scm.org/D1150
Extract 'experimental.evolution' = createmarkers as
'experimental.evolution.createmarkers'.
We keep the new option in the 'experimental.evolution' namespace in order to
stay coherent with other options ('experimental.evolution.bundle-obsmarker'
and 'experimental.evolution.track-operation') ease the renaming as possibly
'evolution.createmarkers'.
Differential Revision: https://phab.mercurial-scm.org/D1149
We replace 'experimental.stabilization=all' by 'experimental.evolution=true'
as we will extract individual config in their own config in later patches.
Differential Revision: https://phab.mercurial-scm.org/D1148
Update the evolution helpers function to support both old-style configuration and
new-style configuration:
experimental.evolution=all is renamed into experimental.evolution=true
experimental.evolution=createmarkers is renamed into
experimental.evolution.createmarkers=true
experimental.evolution=allowunstable is renamed into
experimental.evolution.allowunstable=true
experimental.evolution=exchange is renamed into
experimental.evolution.exchange=true
We choose to not rename individual config options; keeping the same names
would easy the transition for users but it's something that could be easily
done in the future.
Differential Revision: https://phab.mercurial-scm.org/D1147
We want to split the evolution-related configuration and back-out the renaming
from evolution.* to stabilization.*.
First invert the configuration and aliases, so next changesets will be
cleaner.
Differential Revision: https://phab.mercurial-scm.org/D1146
# skip-blame because parsers.c is mechanically rewritten by
clang-format with no semantic change.
Differential Revision: https://phab.mercurial-scm.org/D1170
This gives clang-format the right notion about formatting these struct
initializers, therefore allowing us to automatically format several
additional files.
# skip-blame because this is just a content-free comment addition
Differential Revision: https://phab.mercurial-scm.org/D1169
We want a slightly weird format here so that it's easier to read, but
in order to preserve that we need to disable clang-format.
Differential Revision: https://phab.mercurial-scm.org/D1168
Now that all known options are declared, we setup a warning to make sure it will
stay this way.
We disable the warning in two tests checking other behavior with random options.
We add an experimental -L/--line-range option to 'hg log' taking file patterns
along with a line range using the (new) FILE,FROMLINE-TOLINE syntax where FILE
may be a pattern (matching exactly one file). The resulting history is similar
to what the "followlines" revset except that, if --patch is specified,
only diff hunks within specified line range are shown.
Basically, this brings the CLI on par with what currently only exists in hgweb
through line selection in "file" and "annotate" views resulting in a file log
with filtered patch to only display followed line range.
The option may be specified multiple times and can be combined with --rev and
regular file patterns to further restrict revisions. Usage of this option
requires --follow; revisions are shown in descending order and renames are
followed. Only the --graph option is currently not supported.
The UI is the result of a consensus from review feedback at:
https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-October/106749.html
The implementation spreads between commands.log() and cmdutil module.
In commands.log(), the main loop may now use a "hunksfilter" factory (similar
to "filematcher") that, for a given "rev", produces a filtering function
for diff hunks for a given file context object.
The logic to build revisions from -L/--line-range options lives in
cmdutil.getloglinerangerevs() which produces "revs", "filematcher" and
"hunksfilter" information. Revisions obtained by following files' line range
are filtered if they do not match the revset specified by --rev option. If
regular FILE arguments are passed along with -L options, both filematchers are
combined into a new matcher.
.. feature::
Add an experimental -L/--line-range FILE,FROMLINE-TOLINE option to 'hg log'
command to follow the history of files by line range. In combination with
-p/--patch option, only diff hunks within specified line range will be
displayed. Feedback, especially on UX aspects, is welcome.
We add a 'hunksfilterfn' keyword argument in all functions of the call
stack from changeset_printer.show() to patch.diff(). This is a callable
that will be used to filter out hunks by line range and will be used in
the "-L/--line-range" option of "hg log" command introduced in the
following changesets.
We'll need the same logic in forthcoming changeset to handle --line-range
option in 'hg log' command.
The function lives in scmutil.py (rather than util.py) as it uses match and
pathutil modules.
Use the verbosity aware template keyword introduced earlier. It has the nice
property of being verbosity dependent but in order to customize the obsfate
part, users will need to replace the lobsfate definition from default mapfile
with the one using template functions (by copying the one from test-obsmarker-
template.t for example).
As it's a more advanced use-case, I'm more inclined to have the same code for
the {obsfate} keyword, in the changeset printer and in the default mapfile for
consistency.
But, the definition in default mapfile could be replaced with one based on
template filter to obsfate output customization if it is a big need for users.
Having an obsfate by default in log will be useful for users to understand why
they have obsolete and unstable changesets. Obsfate will only be shown for
obsolete changesets, which only happens if people opt-in to experimental feature.
But when obsolete changeset are visible, it is very useful to understand where
they are. Having it in log could be sufficient for most people, so they don't
have to learn a new command (like obslog which is itself useful in case of
divergences).
For example, when pulling and working directory parent become obsolete:
$ hg pull
...
working directory parent is obsolete! (f936c1697205)
This message comes from the Evolve extension.
Obsfate would comes handy:
$ hg log -G
o changeset: 2:6f91013c5136
| tag: tip
| parent: 0:4ef7b558f3ec
| user: Boris Feld <boris.feld@octobus.net>
| date: Mon Oct 09 16:00:27 2017 +0200
| summary: A
|
| @ changeset: 1:f936c1697205
|/ user: Boris Feld <boris.feld@octobus.net>
| date: Mon Oct 09 16:00:27 2017 +0200
| obsfate: rewritten using amend as 2:6f91013c5136
| summary: -A
|
o changeset: 0:feb4dd822b8c
user: Boris Feld <boris.feld@octobus.net>
date: Tue Oct 09 16:00:00 2017 +0200
summary: ROOT
And once we update, we don't have an obsolete changeset in the log anymore so
we don't show obsfate anymore, most users won't see obsfate often if they
don't have obsolete changeset often:
@ changeset: 2:6f91013c5136
| tag: tip
| parent: 0:4ef7b558f3ec
| user: Boris Feld <boris.feld@octobus.net>
| date: Mon Oct 09 16:00:27 2017 +0200
| summary: A
|
o changeset: 0:feb4dd822b8c
user: Boris Feld <boris.feld@octobus.net>
date: Tue Oct 09 16:00:00 2017 +0200
summary: ROOT
Obsolescence is sometimes used only locally so the obs-marker users is always
the same. Showing the user in this case does not bring much values.
In the case where multiple users rewrite the commit, display the full list of
users. Also show all users in verbose mode.
Introduce an obsfate printer that uses all helpers functions defined in
obsutil to get all the obsfate-related data and format a string according to
the current format in test-obsmarker-template.t.
Then, introduce an obsfate templatekw that uses the obsfateprinter to return a
list of strings.
The goal is not to replace existing obsfate template functions but to propose
a default, good-enough and easily usable obsfate definition for end-users that
don't want to customize it. Such output would ultimately get included in the
default log output.
Here are some output examples for a commit amended:
rewritten using amend as 5:a9b1f8652753 by test (at 1970-01-01 00:00 +0000)
Next patches will make the output dependent on the verbosity.
Exemple of use-cases:
For having the obsfate on a single-line between brackets:
{if(obsfate, " [{join(obsfate, "; ")}]")}
For having the obsfate in several lines:
{if(obsfate, "{obsfate % " Obsfate: {fate}\n"}")}
The heuristics algorithm find possible candidates for move/copy and then check
whether they are actually a copy or move. In some cases, there can be lot of
candidates possible which can actually slow down the algorithm.
This patch introduces a config option
`experimental.copytrace.movecandidateslimit` using which one can limit the
candidates to check. The limit defaults to 100.
Thanks to Yuya for suggesting to skip copytracing for that file with a
warning.
Differential Revision: https://phab.mercurial-scm.org/D987
I have spent a lot of time debugging extensions that failed to load
because we don't include a traceback and I didn't realize I could get
traceback for the extension failure with --traceback. Let's just turn
them on by default, since it should be rare that the user sees these
tracebacks anyway (and if they do, it's not so bad if the extra
traceback pushes them a little harder to report the problem).
Since we already had a test case with --traceback and one without, I
just removed the one with the flag.
Differential Revision: https://phab.mercurial-scm.org/D1164
A mercurial.bdiff module has existed at some point and when I have
built at an old version, some .pyc file or something seems to stick
around and test-extension.t fails. Let's remove the reference to bdiff
and simplify the test.
Differential Revision: https://phab.mercurial-scm.org/D1162
The leading newline before "ERROR:" led to an incorrect lexing of the
message and the newline got lost.
The fixed formatting can be seen in the test case. The reason we
didn't notice before was that the bad formatting just led to the loss
of a blank line in the test. However, there are other cases where it
would be joined with a line saying "Accept this change? [n]" or
"Reference output has changed (run again to prompt changes)".
Differential Revision: https://phab.mercurial-scm.org/D1159
This test fails when run with chg. This commit just makes the test chg
aware by fixing the output of some of the tests.
Test Plan:
Ran the test 'test-extension.t' with and without '--chg' option.
Differential Revision: https://phab.mercurial-scm.org/D1160
Chg disables demandimport on purpose for performance wins and
therefore, it probably makes sense to indicate that demandimport is disabled
when chg is running.
Test Plan:
Ran all the tests.
Differential Revision: https://phab.mercurial-scm.org/D1161
The show extension reads `commands.show.aliasprefix` config in its
`extsetup` and that causes issues with chg. This patch adds that config item
to chg confighash to solve the issue.
Test Plan:
`run-tests.py -l --chg test-show.t`
Differential Revision: https://phab.mercurial-scm.org/D1158
We only want to do I/O in terms of bytes, so lets explode early
instead of recursing forever.
Differential Revision: https://phab.mercurial-scm.org/D1136
The part we are using for pull is now used for push too. As we no longer use
pushkey, pushkey hooks are no longer triggered. This is an obvious backward
incompatible change. We could artificially trigger the pushkey hook within the
bundle2 part, but this seemed too hacky to me.
An option would be to disable by default this new mechanism for a couple of
versions to help people migrate to `txnclose-phase`. I took the liberal and
optimistic path to just turn it on by default directly.
.. bc::
Push no longer triggers a pushkey hook when updating phases. Use the new
`txnclose-phase` and `txnclose-phase` hooks instead.
(Applies when both server and client use version 4.4 or above).
`filecmp` follows symlinks by default, which a `filectx.cmp()` call should not
be doing as it should only compare the requested entry. After this patch, only
the contexts' data are compared, which is the correct contract.
This is a corrected version of D1122.
Differential Revision: https://phab.mercurial-scm.org/D1165
For now all .c and .h files are blacklisted. As they become
clang-formatted, we'll remove them from the blacklist,and then this
test will produce output if there are diffs.
Differential Revision: https://phab.mercurial-scm.org/D1133
Fix regression introduced in D785.
In some circumstances, context.clearunknown can be called before the path is
audited. Audit the path before deleting any conflicting files.
Differential Revision: https://phab.mercurial-scm.org/D1157
D785 regressed behavior in path auditing: files can be deleted if they have a
path that conflicts with a filename from a malicious remote or bundle.
This test demonstrates the problem - the file should not have been deleted.
Differential Revision: https://phab.mercurial-scm.org/D1156
The shelve extensions import and call rebase content without loading the
extension. This is problematic as the config items rebase uses are not
declared and the default value are not set, etc...
The shelve extension should be using core utilities only and the necessary bit
should be moved from rebase into core. In the meantime, I'm taking a small
step to get config registration completed with minimal overhead. The rebase
extension is shipped with core so registering its config option within core is
not a big issue.
This is the last step needed before we can install a warning that enforces all
config to be registered.
The acl extension is usually setup through hooks and never directly activated.
This means the config item declared in the extension are not loaded.
We add the necessary logic to make sure the extensions are loaded before the hook
run.
We register the merge-tools config section (which has an arbitrary base config
value) and the possible sub-attribute. The sub-attribute has to be registered
first or at the same time otherwise the '.*' item would shadow them.
Merge tools could include "." in their name so we can't constrain any more
than just ".*".
Delta chains can become quite sparse if there is a lot of unrelated data between
relevant pieces. Right now, revlog always reads all the necessary data for the
delta chain in one single read. This can lead to a lot of unrelated data to be
read (see issue5482 for more details).
One can use the `experimental.maxdeltachainspan` option with a large value
(or -1) to easily produce a very sparse delta chain.
This change introduces the ability to slice the chunks retrieval into multiple
reads, skipping large sections of unrelated data. Preliminary testing shows
interesting results. For example the peak memory consumption to read a manifest
on a large repository is reduced from 600MB to 250MB (200MB without
maxdeltachainspan). However, the slicing itself and the multiple reads can have
an negative impact on performance. This is why the new feature is hidden behind
an experimental flag.
Future changesets will add various parameters to control the slicing heuristics.
We hope to experiment a wide variety of repositories during 4.4 and hopefully
turn the feature on by default in 4.5.
As a first try, the algorithm itself is prone to deep changes. However, we wish
to define APIs and have a baseline to work on.
When a merge commit creates an empty diff in the revlog, its offset may still
be quite far from the end of the previous chunk.
Skipping these empty chunks may reduce read size significantly.
In most cases, there is no gain, and in some cases, little gain.
On my clone of pypy, `hg manifest` reads 65% less bytes (96140 i/o 275943) for
revision 4260 by ignoring the only empty trailing diff.
For revision 2229, 35% (34557 i/o 53435)
Sadly, this is difficult to reproduce, as hg clone can make its own different
structure every time.
