Summary: Updated the global help summaries that are displayed for each command when you run 'hg help' and fixed corresponding tests
Reviewed By: markbt, kulshrax
Differential Revision: D12832280
fbshipit-source-id: 950dad1c805feab573d7d0182da523ae12299d3b
Summary:
tweakdefaults renamed core hg's `grep` to `histgrep`, and added a `hg grep` that behaves more like `git grep`, searching the working copy. This diff folds those changes into core.
The config changes from
```
[tweakdefaults]
allowfullrepohistgrep = False
```
to
```
[histgrep]
allowfullrepogrep = False
```
Reviewed By: quark-zju
Differential Revision: D10435279
fbshipit-source-id: ad3d1da5824511a612111715e46119d70066050f
Summary:
Reorganise the top-level help commands to more useful categories, allowing them
to be listed in a custom order.
Reviewed By: phillco
Differential Revision: D10423184
fbshipit-source-id: 17f02ae201493397a448d108e781eca28a7b1d44
Summary: Make a few help messages clearer.
Reviewed By: phillco
Differential Revision: D10356915
fbshipit-source-id: 277d4cecbd17b647d6dd01209ff6f93a926d37d4
Summary:
Replace the default help for Mercurial with a curated list of interesting
commands, categorized by their use case.
Reviewed By: phillco
Differential Revision: D10356916
fbshipit-source-id: 65e578a4bfde7b0ad04e7107f4e77d8ea882d78a
Summary:
This extension exposes only the `record` command which can be easily
moved to core. This commit achieves the same.
Reviewed By: ikostia
Differential Revision: D10360759
fbshipit-source-id: 25f0c46aa3fa9b19ab8ba03a6b4e8598bc003c7a
Summary:
The extension only offers one command i.e. `show` which can move into
core.
Reviewed By: ikostia
Differential Revision: D10302192
fbshipit-source-id: 9473ec8c80e52506e1b7de62b2c90a51c29419c1
Summary:
Parts of the treedirstate implementation were left in the extension. Since
treestate is now in core, and the two are intertwined, treedirstate should be
in core, too.
In doing so:
- Change the garbage collection behaviour to match that of treestate.
- Use the treestate config options for configuring repacking and garbage
collection.
- Make more of the code common.
Reviewed By: quark-zju
Differential Revision: D10258265
fbshipit-source-id: 89e82bc7662a3d1251fa9886751897cfc46cd66a
Summary:
This would make tests run on treedirstate.
To avoid issues with Eden pulling from a non-eden treedirstate repo,
treedirstate is changed to be "always on" and disables itself on an eden repo.
The extension list is changed to a set for efficient `__contains__` test.
Reviewed By: phillco
Differential Revision: D7769804
fbshipit-source-id: d328fe51ef67c4730cfc53f43bdfc48c2765c541
Summary:
This allows people to silence hints as they like. It's done by modifying
user hgrc.
Reviewed By: markbt
Differential Revision: D7392133
fbshipit-source-id: 1365294217db92dfb3a0c81332a9fefd164795d4
Summary:
This adds the ability to specify a config file to be used during the
command. This is useful during clones for letting the clone command use the
given repositories system specified repo-specific hgrc file.
Reviewed By: quark-zju
Differential Revision: D7311576
fbshipit-source-id: a97d8ebada2e0bea27c75a7650df8ede00dc10c6
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
# skip-blame because this was mechanically rewritten the following script. I
ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t
ones appear to be, and they run without addition failures on both Windows and
Linux.
import argparse
import os
import re
ap = argparse.ArgumentParser()
ap.add_argument('path', nargs='+')
opts = ap.parse_args()
globre = re.compile(r'^(.*) \(glob\)(.*)$')
for p in opts.path:
tmp = p + '.tmp'
with open(p, 'rb') as src, open(tmp, 'wb') as dst:
for line in src:
m = globre.match(line)
if not m or '$LOCALIP' in line or '*' in line:
dst.write(line)
continue
if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'):
dst.write(line)
continue
dst.write(m.group(1) + m.group(2) + '\n')
os.unlink(p)
os.rename(tmp, p)
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
Upon pull or unbundle, we display a message with the range of new revisions
fetched. This revision range could readily be used after a pull to look out
what's new with 'hg log'. The algorithm takes care of filtering "obsolete"
revisions that might be present in transaction's "changes" but should not be
displayed to the end user.
The test fails when run with the '--chg' option. Therefore, this
commit modifies the test to make it compatible with chg.
Test Plan:
Ran 'test-globalopts.t' with and without the '--chg' option.
Differential Revision: https://phab.mercurial-scm.org/D913
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.
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.
We introduce the "internals" help topic, which renders an index of
available sub-topics. The sub-topics themselves are still not
reachable via the help system.
There are a lot of non-human consumers of Mercurial. And the challenges
and considerations for machines consuming Mercurial is significantly
different from what humans face.
I think there are enough special considerations around how machines
consume Mercurial that a dedicated help topic is warranted. I concede
the audience for this topic is probably small compared to the general
audience. However, lots of normal Mercurial users do things like create
one-off shell scripts for common workflows that I think this is useful
enough to be in the install (as opposed to, say, a wiki page - which
most users will likely never find).
This text is by no means perfect. But you have to start somewhere. I
think I did cover the important parts, though.
Given that this path is going to abort, it seems OK to spend the time to do an
alternate lookup to better inform the user. The path returned by util.pathto()
ends with '/' at least in some cases, so os.path.relpath() is used instead,
which requires python 2.6.
"working directory" is the standard term, we should use it consistently.
But I didn't touch the hint, "run 'hg update' to get a working copy", because
"get a working directory" sounds a bit odd.
When 62900f2373fa introduced phases to the `hg log --debug` output, it
also disabled outputting public phase. At the same time, it always
shows phases in the default template, `hg log --debug -T default`.
Those two should produce the same output, but they don't.
I think it makes a lot more sense to always show all phases. There's
already loss of backwards compatibility in this case when using a
newer hg on an old hg repo, since draft commits will show up in the
output of `hg log --debug`.
Finally, I just don't think that any sort of information should be
hidden with --debug. This flag should be about showing as much
information as possible.
The old docs emphasized topological heads rather than branch heads and
incorrectly defined branch heads as not having children rather than
descendants.
