Summary:
It was used to patch Python's `SocketServer`. Since we no longer use
`SocketServer` in command server's code path. The extension can be removed.
Reviewed By: ryanmce
Differential Revision: D6974976
fbshipit-source-id: 52353b55d812e494756833cefba896b6e64eaf9e
Summary:
Previously `hg server` uses `HGPORT` that might be in use. This patch uses
`-p 0 --port-file ...` so `hg server` always gets assigned a free port.
The change was first made by the following Ruby script:
```
re = /^ \$ hg serve(.*) -p \$(HGPORT[12]?) (.*[^\\])$\n \$/
Dir['*.t'].each do |path|
old = File.read(path)
new = old.lines.map do |l|
next l if l[/\(glob\)/] or not l['$HGPORT'] or l[/^ [$>]/]
"#{l.chomp} (glob)\n"
end.join.gsub re, <<-'EOS'.chomp
$ hg serve\1 -p 0 --port-file $TESTTMP/.port \3
$ \2=`cat $TESTTMP/.port`
$
EOS
File.write(path, new) if old != new
end
```
Then there are some manual changes:
run-tests.py: It now treats `$HGPORT` in output as glob pattern `*`, since
it does not know the assigned value in tests.
test-bookmarks-pushpull.t, test-https.t: Some `hg pull`s were changed to use
explicit paths instead of relying on `.hgrc` since the test restarts the
server and `.hg/hgrc` having an outdated URL.
test-schemes.t: The test writes `$HGPORT` to `.hgrc` before assigning it.
Changed the order so the correct `$HGPORT` is written.
test-patchbomb-tls.t: Changed `(?) (glob)` to `(glob) (?)`.
Reviewed By: DurhamG
Differential Revision: D6925398
fbshipit-source-id: d5c10476f43ce23f9e99618807580cf8ba92595c
Summary:
Check to see if the module documentation is None before trying to call
`splitlines()` on it.
Reviewed By: singhsrb
Differential Revision: D6919043
fbshipit-source-id: 93c458cde9643a3f1b2d6fe6eb56fa312ae2a192
Summary:
This is similar to `debugdata`, but instead of taking a file revision (or
file node in remotefilelog's case), it takes a revset.
This is more useful practically, since the user would know commit hashes
easily but file nodes are hidden from the UI.
This is intended to make it easier to investigate LFS contents.
Reviewed By: DurhamG, ryanmce
Differential Revision: D6891770
fbshipit-source-id: 415da9b773c30830a48c09eda9f1854c416e3222
Summary: `fastverifier` was sometimes being overriden by `shallowverifier` when remotefilelog was enabled. Since the latter is a subset of the former, let's just fold both into the core verifier code backed by a config, `verify.skipmanifests`, that we can default to true.
Reviewed By: DurhamG
Differential Revision: D6882222
fbshipit-source-id: 9f337ca031a070425ccdc9ee02f6765e68436da9
Summary:
With `buck build`, the single hg binary won't be guarnateed to have
access to i18n messages because directories like `mercurial/locale`
do not exist on filesystem. It could also mess up with `PYTHONPATH`
somehow because the python binary wrapper sometimes ignores
`PYTHONPATH`.
So let's add a hghave feature for it. And gate troublesome tests
with `#if normal-layout`.
Reviewed By: DurhamG, phillco
Differential Revision: D6879876
fbshipit-source-id: 3d63605b55c8f7096093b89be824add2ec491f81
Summary:
Since we have `debugbuilddag` as a builtin command, and `drawdag` is
pretty useful for writing clean test cases. Let's inline it. This would
simplify many tests since `drawdag=..." is no longer needed.
Reviewed By: DurhamG
Differential Revision: D6827925
fbshipit-source-id: b749f57fd5c55b2cb000dd2da2c2f9bc2386a519
Summary:
The last diff lost most of its content after v2 was submitted. Resend.
(Note: this ignores all push blocking failures!)
Reviewed By: quark-zju
Differential Revision: D6795055
fbshipit-source-id: ed5f6d5eba9f8cfd505ed4ba1724110414b685f8
Summary:
`hg version`, as of the last path, currently prints:
```
Mercurial Distributed SCM (version 20180123_174746_5cb750b72031)
Facebook Mercurial release: UNKNOWN-RELEASE
```
There's no need for us to print the second line now that the first represents the internal version ID.
(Note: this ignores all push blocking failures!)
Reviewed By: quark-zju
Differential Revision: D6794821
fbshipit-source-id: 499828832a0acb066adc260f852c3a743e41a563
Summary:
The keyword extension is rarely used. And it breaks sshaskpass because
Python standard library `collections` (which does not use absolute import)
will import the wrong `keyword` module:
$ hg pull ssh://localhost/foo --debug
pulling from ssh://localhost/foo
running SSH_ASKPASS=/tmp/tmpj_6pDJttysrv/2991364.sh DISPLAY=localhost:10.0 TTYSOCK=/tmp/tmpj_6pDJttysrv/2991364 ssh -oControlMaster=no localhost 'hg -R foo serve --stdio'
sending hello command
sending between command
remote: Traceback (most recent call last):
remote: File "/usr/lib64/python2.7/site-packages/hgext/sshaskpass.py", line 43, in <module>
remote: import collections
remote: File "/usr/lib64/python2.7/collections.py", line 10, in <module>
remote: from keyword import iskeyword as _iskeyword
remote: File "/usr/lib64/python2.7/site-packages/hgext/keyword.py", line 93, in <module>
remote: from mercurial.i18n import _
remote: File "/usr/lib64/python2.7/site-packages/mercurial/i18n.py", line 15, in <module>
remote: from . import (
remote: File "/usr/lib64/python2.7/site-packages/mercurial/encoding.py", line 15, in <module>
remote: from . import (
remote: File "/usr/lib64/python2.7/site-packages/mercurial/error.py", line 17, in <module>
remote: from . import pycompat
remote: File "/usr/lib64/python2.7/site-packages/mercurial/pycompat.py", line 22, in <module>
remote: import cookielib
remote: File "/usr/lib64/python2.7/cookielib.py", line 32, in <module>
remote: import re, urlparse, copy, time, urllib
remote: File "/usr/lib64/python2.7/urlparse.py", line 123, in <module>
remote: from collections import namedtuple
remote: ImportError: cannot import name namedtuple
Reviewed By: singhsrb
Differential Revision: D6766686
fbshipit-source-id: af67a4d8c736158951c737b790904ba11419d432
Summary:
This enables clindex for its nodemap. Verification is turned off by default
for the performance win since we have been running verification in
production for a while.
Reviewed By: phillco
Differential Revision: D6751412
fbshipit-source-id: bc3e87df86e86a758392bdd4aef3e282f397fe04
Summary:
It's pretty handy. The implementation is simple and clean. So move it from
contrib and enable it by default. "import"s are adjusted to make the module
checker happy.
Security and UX wise, since we have `--debugger` already, adding another
REPL seems fine.
Test Plan: Ran all tests
Reviewers: phillco, #mercurial
Reviewed By: phillco
Differential Revision: https://phabricator.intern.facebook.com/D6741283
Signature: 6741283:1516225662:ddc19a663e7ecef2a1fdaa5041f308dc838a8471
Summary:
`lfs` is the better large file solution. `largefiles` is rarely used, and
its implementation is less clean. So let's remove it.
Test Plan:
Ran all tests. A subrepo test was removed instead of cleaned up since the
longer term plan is to also drop subrepo support.
Reviewers: phillco, #mercurial
Reviewed By: phillco
Differential Revision: https://phabricator.intern.facebook.com/D6740361
Signature: 6740361:1516225594:555e3803571ad05e0434021897a2823ac99347ae
Summary:
Moves the moreversion extension to hgext/ and updates the core setup.py
to process it. Eventually we should get rid of this and store the version number
as the normal Mercurial number, but that can happen later.
Test Plan:
make local && ./hg version
Mercurial Distributed SCM (version 4.4.2+8922-aa235b4cbeac+20180110)
Facebook Mercurial release: UNKNOWN-RELEASE
Reviewers: phillco, #mercurial
Reviewed By: phillco
Differential Revision: https://phabricator.intern.facebook.com/D6696199
Signature: 6696199:1515621476:7835f9110ec143737c488faf49cf547eee8f918e
Summary:
We changed the location of infinitepush which exposed it to the
additional test that failed. This commit fixes infinitepush to address that
test.
Test Plan: Ran all the tests.
Reviewers: rmcelroy, #mercurial, #sourcecontrol
Reviewed By: rmcelroy
Differential Revision: https://phabricator.intern.facebook.com/D6691691
Signature: 6691691:1515578616:1ab451468835cc67a35f1d4d6e56a71f48db47e1
Summary:
This is part of the overall plan to move extensions from fb-hgext to
hgext. Follow up commits will address some of the test issues and move the
infinitepush related tests out of fb-hgext to hgext.
Test Plan: Ran all the tests.
Reviewers: rmcelroy, #mercurial, #sourcecontrol
Reviewed By: rmcelroy
Differential Revision: https://phabricator.intern.facebook.com/D6691670
Signature: 6691670:1515578586:8d7836aebb474856559c6dbe6fe2f572c8bdf7f1
setup.py needs an explicit list of all the directory modules, otherwise it
doesn't build them. This caused test-help to fail when run without -l because
they weren't copied to the target directory. I'm not sure how the tests have
been passing actually. My guess is they were importing the extensions from the
system python.
Summary: Moves the extension itself.
Test Plan:
make local && ./run-tests.py
A future patch fixes the tests once
fastmanifest is also moved.
Reviewers: phillco, #mercurial
Reviewed By: phillco
Differential Revision: https://phabricator.intern.facebook.com/D6684580
Signature: 6684580:1515521896:68a4d648d9f5433d6eeda8be01740fbe12abf44e
Summary:
Some new help contents are now generated with test-help.t
Depends on D6675351
Test Plan: - test-help.t is passing now
Reviewers: #sourcecontrol
Differential Revision: https://phabricator.intern.facebook.com/D6675363
Summary: It was missed by whoever was adding hsql to this repo
Test Plan: tests are passing now
Reviewers: rmcelroy, ikostia, #mercurial
Reviewed By: rmcelroy
Differential Revision: https://phabricator.intern.facebook.com/D6674927
Signature: 6674927:1515432467:705219df9ef28e218923aafe720c8f908f16be67
The command displays basic data about all format variants registered for repo
upgrades. This gives a quick way to peek into a repository format.
The 'fm.write()' calls are very independent because more data will be added in
later changeset. Having more separate call make the later patch clearer.
This is a short topic to explain how command-line flags can be specified.
Some users have been confused by hg offerring different flag syntax than some
other libraries, so it'd be nice to point them to this rather than explaining
it every time.
Differential Revision: https://phab.mercurial-scm.org/D1270
This new debugcommand prints the capabilities of any remote in a human friendly
way. Improved bundle2 capabilities support will be introduced in the next
changesets.
Add an option that only ignores whitespaces at EOL. The name of the option is
the same as Git.
.. feature::
Added `--ignore-space-at-eol` diff option to ignore whitespace differences
at line endings.
Differential Revision: https://phab.mercurial-scm.org/D422
This is only useful on Windows, and avoids the need to use Internet Explorer to
build the certificate chain. I can see this being extended in the future to
print information about the certificate(s) to help debug issues on any platform.
Maybe even perform some of the python checks listed on the secure connections
wiki page. But for now, all I need is 1) a command that can be invoked in a
setup script to ensure the certificate is installed, and 2) a command that the
user can run if/when a certificate changes in the future.
It would have been nice to leverage the sslutil library to pick up host specific
settings, but attempting to use sslutil.wrapsocket() failed the
'not sslsocket.cipher()' check in it and aborted.
The output is a little more chatty than some commands, but I've seen the update
take 10+ seconds, and this is only a debug command.
If the matching command lives in an in-tree extension (which is all we
scan for), and the user has disabled that extension with
"extensions.<name>=!", we were not finding it, because the path in
_disabledextensions was the empty string. If the user had set
"extensions.<name>=!<valid path>" it would work, so it seems like just
a mistake that it didn't work.
This includes one test showing how disabling a command with e.g.
"extensions.rebase=!" results in the command not being
suggested. We'll fix that next.
These are some simple cases. More to come in a future change.
Reviewers: krbullock
Reviewed By: krbullock
Differential Revision: https://phab.mercurial-scm.org/D4
AFAICT this was mostly a bunch of copy pasta. The only variation is
some pages defined a "value" attribute. The "query" variable will
just be empty on pages that don't accept it. So let's consolidate
the template and remove the redundancy.
cmdutil.command wasn't a member of the registrar framework only for a
historical reason. Let's make that happen. This patch keeps cmdutil.command
as an alias for extension compatibility.
That command make sure caches are updated. This is based on
'localrepo.updatecaches' so when we move support for new cache in that function this
command will benefit from it.
Internal merge tool :dump implies premerge. Therefore, files aren't
dumped, if premerge runs successfully.
This undocumented behavior might confuse users, if they want to always
dump files. But just making :dump omit premerge might cause backward
compatibility issue for existing automation.
This patch adds new internal merge tool :forcedump, which works as
same as :dump, but omits premerge always.
Internal tools annotated with "nomerge" should merge "change and
delete" correctly, but _forcedump() can't. Therefore, it is annotated
with "mergeonly" to always omit premerge, even though it doesn't merge
files actually.
This patch also adds explanation about premerge to :dump, to clarify
how :dump actually works.
BTW, this patch specifies internal tools with "internal:" prefix in
newly added test scenario in test-merge-tools.t, even though this
prefix is already deprecated. This is only for similarity to other
tests in test-merge-tools.t.
"merge-tools" help topic has described that the merge of the file
fails if no tool is found to merge binary or symlink, since
9da9bced2226 (or Mercurial 1.7), which based on (already removed)
MergeProgram wiki page.
But even at that revision, and of course now, merge of the file
doesn't fail automatically for binary/symlink. ":prompt" (or
equivalent logic) is used, if there is no appropriate tool
configuration for binary/symlink.
This patch adds --binary option to `hg diff` and `hg export` to allow more
control about when binary diffs are displayed in Git mode as well as some
tests to verify it behaves correctly (issue5510).
We now have a dedicated help topic to describe bundle specification
strings. Let's update `hg bundle`'s documentation to reflect its
existence.
While I was hear, I also tweaked some wording which I felt was out
of date and needed tweaking. Specifically, `hg bundle` no longer
just deals with "changegroup" data: it can also generate files
that have non-changegroup data.
I softly formalized the concept of a "bundle specification" a while
ago when I was working on clone bundles and stream clone bundles and
wanted a more robust way to define what exactly is in a bundle file.
The concept has existed for a while. Since it is part of the clone
bundles feature and exposed to the user via the "-t" argument to
`hg bundle`, it is something we need to support for the long haul.
After the 4.1 release, I heard a few people comment that they didn't
realize you could generate zstd bundles with `hg bundle`. I'm
partially to blame for not documenting it in bundle's docstring.
Additionally, I added a hacky, experimental feature for controlling
the compression level of bundles in 054e64c4d837. As the commit
message says, I went with a quick and dirty solution out of time
constraints. Furthermore, I wanted to eventually store this
configuration in the "bundlespec" so it could be made more flexible.
Given:
a) bundlespecs are here to stay
b) we don't have great documentation over what they are, despite being
a user-facing feature
c) the list of available compression engines and their behavior isn't
exposed
d) we need an extensible place to modify behavior of compression
engines
I want to move forward with formalizing bundlespecs as a user-facing
feature. This commit does that by introducing a "bundlespec" help
page. Leaning on the just-added compression engine documentation
and API, the topic also conveniently lists available compression
engines and details about them. This makes features like zstd
bundle compression more discoverable. e.g. you can now
`hg help -k zstd` and it lists the "bundlespec" topic.
Add information about tree manifests, copy edit the text and fix up a few
ambiguities.
The document also contains a few additional fixes from Siddharth Agarwal
<sid0@fb.com>, who used it to build a parser for changegroups in Rust.
Now that the feature no longer lives in the extension, we document it in the
help of the core config. This include the new 'ui.color' option introduced in
the previous changesets.
As a result the color extensions can now be deprecated.
This is a documentation patch only; color is still disabled by default.
This is the last bits we needed to move out of the extensions. 'hgext/color.py'
now only contains logic to changes the default color behavior to 'auto'.
However, more cleanups are on the way and we need to document the new config
directly in core.
This new option control whether or not color will be used. It mirror the behavior
of '--color'. I usually avoid adding new option to '[ui]' as the section is
already filled with many option. However, I feel like 'color' is central enough
to deserves a spot in this '[ui]' section.
For now the option is not documented so it is still marked as experimental. Once
it get documented and official, we should be able to deprecate the color
extensions.
There is more cleanup to do before that documentation is written, but we need
this option early to made them. Having that option will allow for more cleanup
of the initialisation process and proper separation between color
configuration.
If we want to be able to move the initialisation in core, we need core to be
aware of that '--color' flag at all time. So we now have the definition in core. That flag
is currently unprocessed without the extensions (will be fixed soon). In
addition the default value for this flag in core is 'never'. Enabling the
extensions change that default value to 'auto'.
Previously, we have keywords like "(DEPRECATED)" and "(EXPERIMENTAL)" to
hide command line options in non-verbose help output.
However, sometimes an option is neither deprecated nor experimental. It's
well-tested and working, but just not designed to average users. This patch
adds a keyword "(ADVANCED)" to fit in such use cases.
Thanks rom1dep for the suggestion of the word "advanced".
This patch replaces hardcoded 127.0.0.1 with $LOCALIP in all tests.
Till now, the IPv6 series should make tests pass on common IPv6 systems
where the local device has the address "::1" and the hostname "localhost"
resolves to "::1".
This moves the global flag and the --pager=yes logic into core. Only
functionality change is that users now always get a --pager flag and
can enable the pager via the flag without the extension active.
Moving the flag into core exposes a defect in the ro localization,
which will have to be corrected later.
This patch also makes some expected output lines in tests glob-ed for
persistence of them.
BTW, files below aren't yet changed in 2017, but this patch also
updates copyright of them, because:
- mercurial/help/hg.1.txt
almost all of "man hg" output comes from online help of hg
command, and is already changed in 2017
- mercurial/help/hgignore.5.txt
- mercurial/help/hgrc.5
"copyright 2005-201X Matt Mackall" in them mentions about
copyright of Mercurial itself
Currently, if Mercurial introduces a new repository/store feature or
changes behavior of an existing feature, users must perform an
`hg clone` to create a new repository with hopefully the
correct/optimal settings. Unfortunately, even `hg clone` may not
give the correct results. For example, if you do a local `hg clone`,
you may get hardlinks to revlog files that inherit the old state.
If you `hg clone` from a remote or `hg clone --pull`, changegroup
application may bypass some optimization, such as converting to
generaldelta.
Optimizing a repository is harder than it seems and requires more
than a simple `hg` command invocation.
This commit starts the process of changing that. We introduce
`hg debugupgraderepo`, a command that performs an in-place upgrade
of a repository to use new, optimal features. The command is just
a stub right now. Features will be added in subsequent commits.
This commit does foreshadow some of the behavior of the new command,
notably that it doesn't do anything by default and that it takes
arguments that influence what actions it performs. These will be
explained more in subsequent commits.
Selecting single and multiple revisions is closely related, so let's
put it in one place, so users can easily find it. We actually did not
even point to "hg help revsets" from "hg help revisions", but now that
they're on a single page, that won't be necessary.
All the hgweb templates include mercurial.js in their header. All
the hgweb templates have the same <script> boilerplate to run
process_dates(). This patch factors that function call into
mercurial.js as part of a DOMContentLoaded event listener.
It was an extension just because there were several dependency cycles I
needed to address.
I don't add 'chgserver' to extensions._builtin since chgserver is considered
an internal extension so nobody should enable it by their config.
The ability to negate any boolean flags itself is great, but I think we are not
ready to expose the help side of it yet.
First, while there exist a handful of such flags whose default value can be
changed (eg: git diff, patchwork confirmation), there is only a few of them. The
users who benefit the most from this change are alias users and large
installation that can deploy extension to change behavior (eg: facebook
tweakdefault). So the majority of user who will be affected by a large change
to command help that is not yet relevant to them. (I expect this to become
relevant when ui.progressive start to exists).
Below is an example of the impact of the new help on 'hg help diff':
-r --rev REV [+] revision
-c --change REV change made by revision
-a --[no-]text treat all files as text
-g --[no-]git use git extended diff format
--[no-]nodates omit dates from diff headers
--[no-]noprefix omit a/ and b/ prefixes from filenames
-p --[no-]show-function show which function each change is in
--[no-]reverse produce a diff that undoes the changes
-w --[no-]ignore-all-space ignore white space when comparing lines
-b --[no-]ignore-space-change ignore changes in the amount of white space
-B --[no-]ignore-blank-lines ignore changes whose lines are all blank
-U --unified NUM number of lines of context to show
--[no-]stat output diffstat-style summary of changes
--root DIR produce diffs relative to subdirectory
-I --include PATTERN [+] include names matching the given patterns
-X --exclude PATTERN [+] exclude names matching the given patterns
-S --[no-]subrepos recurse into subrepositories
Another issue with the current state of help, the default value for the
flag is not conveyed to the user. For example in the 'backout' help, there is
no real distinction between "--[no-]backup" (default to True) and "--[no-]keep"
(default) to False:
--[no-]backup no backups
--[no-]keep do not modify working directory during strip
In addition, I've discussed with Augie Fackler and the last batch of the work on
this have burned him out quite some. Therefore he is not intending to perform
any more work on this topic. Quoting him, he would rather see the help part
backed out than spending more time on it.
I do not think we are ready to expose this to users in 4.0 (freeze in a week),
especially because we cannot expect quick improvement on these aspect as this
topic no longer have an owner. We should be able to reintroduce that change in
the future when someone get back on it and the main issues are solves:
* Introduction of ui.progressive makes it relevant for a majority of user,
* Current default value are efficiently conveyed to the user.
(In addition, the excerpt from diff help show that we still have some issue with
some negative option like '--nodates' so further improvement are probably
welcome there.)
That is, help gets tweaked thus:
global options ([+] can be repeated):
-v --[no-]verbose enable additional output
Other proposals have included:
global options ([+] can be repeated, options marked [?] are boolean flags):
-v --verbose[?] enable additional output
and
global options ([+] can be repeated, options marked [^] are boolean flags):
-v --verbose[^] enable additional output
which avoid the unfortunate visual noise in this patch. In this
version's favor, it's consistent with what I'm used to seeing in man
pages and similar documentation venues.
We already support multiple primitive for listing files, which were
affected by the current changeset.
This patch adds files() which returns files of the current changeset
matching a given pattern or fileset query via the "set:" prefix.
Now that we have a mechanism for declaring path sub-options, we can
start to pile on features!
Many power users have expressed frustration that bare `hg push`
attempts to push all local revisions to the remote. This patch
introduces the "pushrev" path sub-option to control which revisions
are pushed when no "-r" argument is specified.
The value of this sub-option is a revset, naturally.
A future feature addition could potentially introduce a "pushnames"
sub-options that declares the list of names (branches, bookmarks,
topics, etc) to push by default. The entire "what to push by default"
feature should probably be considered before this patch lands.
Before this patch, "hg help topic.section" might show unexpected
section of help topic in some encoding.
It applies str.lower() instead of encoding.lower(str) on translated
message to search section case-insensitively, but some encoding uses
0x41(A) - 0x5a(Z) as the second or later byte of multi-byte character
(for example, ja_JP.cp932), and str.lower() causes unexpected result.
To search section of help topic by translated section name correctly,
this patch replaces str.lower() by encoding.lower(str) for both query
string (in commands.help()) and translated help text (in
minirst.getsections()).
Before this patch, when printing help text using `hg help`, or `hg log -h`,
the output will wrap at 78 chars even if the user has a bigger terminal width
and there is no config option to change it, making the experience different
from the commonly used `man` tool.
This patch introduces a new config option `ui.textwidth`, which replaces the
hardcoded number. It's set to 78 by default to maintain compatibility. When
set to 0, `hg help` will behave more like `man`.
